Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Nov 10, 2009

  1. jrn

    Show usage string for 'git merge-one-file -h'

    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    jrn authored committed

May 09, 2009

  1. Alex Riesen

    Clarify kind of conflict in merge-one-file helper

    Not as verbose as the recursive merge driver, but better still.
    
    Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    raalkml authored committed

Mar 19, 2008

  1. Junio C Hamano

    git-merge-one-file: fix longstanding stupid thinko

    When a merge result creates a new file, and when our side already has a
    file in the path, taking the merge result may clobber the untracked file.
    However, the logic to detect this situation was totally the wrong way.  We
    should complain when the file exists, not when the file does not exist.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored

Dec 11, 2007

  1. Junio C Hamano

    Support a merge with conflicting gitlink change

    merge-recursive did not support merging trees that have conflicting
    changes in submodules they contain, and died.  Support it exactly the
    same way as how it handles conflicting symbolic link changes --- mark it
    as a conflict, take the tentative result from the current side, and
    letting the caller resolve the conflict, without dying in merge_file()
    function.
    
    Also reword the error message issued when merge_file() has to die
    because it sees a tree entry of type it does not support yet.
    
    [jc: fixed up initial draft by Finn Arne Gangstad]
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored

Jul 09, 2007

  1. Junio C Hamano

    Fix merge-one-file for our-side-added/our-side-removed cases

    When commit ed93b44 changed the script so that it does not
    touch untracked working tree file, we forgot that we still
    needed to resolve the index entry (otherwise they are left
    unmerged).
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored

Jul 03, 2007

  1. Junio C Hamano

    Rewrite "git-frotz" to "git frotz"

    This uses the remove-dashes target to replace "git-frotz" to "git frotz".
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored

Jun 07, 2007

  1. Junio C Hamano

    War on whitespace

    This uses "git-apply --whitespace=strip" to fix whitespace errors that have
    crept in to our source files over time.  There are a few files that need
    to have trailing whitespaces (most notably, test vectors).  The results
    still passes the test, and build result in Documentation/ area is unchanged.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored

Dec 22, 2006

  1. dscho

    Use git-merge-file in git-merge-one-file, too

    Would you believe? I edited git-merge-one-file (note the missing ".sh"!)
    when I submitted the patch which became commit e2b7008...
    
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    dscho authored Junio C Hamano committed

Oct 28, 2006

  1. merge: loosen overcautious "working file will be lost" check.

    The three-way merge complained unconditionally when a path that
    does not exist in the index is involved in a merge when it
    existed in the working tree.  If we are merging an old version
    that had that path tracked, but the path is not tracked anymore,
    and if we are merging that old version in, the result will be
    that the path is not tracked.  In that case we should not
    complain.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Jul 10, 2006

  1. Pavel Roskin

    Fix more typos, primarily in the code

    The only visible change is that git-blame doesn't understand
    "--compability" anymore, but it does accept "--compatibility" instead,
    which is already documented.
    
    Signed-off-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    proski authored Junio C Hamano committed

Apr 13, 2006

  1. Shell utilities: Guard against expr' magic tokens.

    Some words, e.g., `match', are special to expr(1), and cause strange
    parsing effects.  Track down all uses of expr and mangle the arguments
    so that this isn't a problem.
    
    Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Mark Wooding authored Junio C Hamano committed

Jan 06, 2006

  1. Alex Riesen

    trivial: remove the dots at the end of file names from merge-one-file

    to make the output more friendly to mouse copy-paste.
    
    Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    raalkml authored Junio C Hamano committed

Dec 07, 2005

  1. git-merge-one: new merge world order.

    This does two things:
    
     - Use new --stage=2 option to create the working tree file with
       leading paths and correct permission bits using
       checkout-index, as before.
    
     - Make sure we do not confuse "merge" program when the file
       being merged has an unfortunate name, '-L'.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Dec 06, 2005

  1. git-merge-one-file: resurrect leading path creation.

    Since we do not use git-update-index followed by
    git-checkout-index -u to create the half-merged file on
    conflicting case anymore, we need to make sure the leading
    directories are created here.
    
    Maybe a better solution would be to allow update-index to add to
    higher stage, and checkout-index to extract from such, but that
    is a change slightly bigger than I would like to have so close
    to 1.0, so this should do for now.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Dec 02, 2005

  1. merge-one-file: make sure we do not mismerge symbolic links.

    We ran "merge" command on O->A, O->B, A!=B case without
    verifying the path involved is not a symlink.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
  2. merge-one-file: make sure we create the merged file.

    The "update-index followed by checkout-index" chain served two
    purposes -- to collapse the index to "our" version, and make
    sure that file exists in the working tree.  In the recent update
    to leave the index unmerged on conflicting path, we wanted to
    stop doing the former, but we still need to do the latter (we
    allow merging to work in an un-checked-out working tree).
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
  3. git-merge-one-file: do not worry about 'rmdir -p' not removing direct…

    …ory.
    
    
    9ae2172 used "rmdir -p"
    carelessly, causing the more important "git-update-index
    --remove" to be skipped.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Nov 30, 2005

  1. merge-one-file: leave unmerged index entries upon automerge failure.

    When automerge fails, we used to collapse the path to stage0
    from "our" branch, to help "diff-files" users to view the
    half-merged state against the current HEAD.  Now diff-files has
    been taught how to compare with unmerged stage2,leaving them
    unmerged is a better thing to do, especially this prevents the
    unresolved conflicts to be committed by mistake.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Linus Torvalds authored Junio C Hamano committed

Nov 20, 2005

  1. merge-one-file: use rmdir -p

    The flag is universally available, even on VMS; use it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
  2. merge-one-file: remove empty directories

    When the last file in a directory is removed as the result of a
    merge, try to rmdir the now-empty directory.
    
    [jc: We probably could use "rmdir -p", but for now we do that by
    hand for portability.]
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Nov 12, 2005

  1. merge-one-file: use empty- or common-base condintionally in two-stage…

    … merge.
    
    If two sides added the same path completely different thing, it is
    easier to see the merge pivoting on /dev/null.  So check the size of
    the common section we have found, and empty it if it is too small.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
  2. merge-one-file: use common as base, instead of emptiness.

    Unlike the previous round that merged the path added differently
    in each branches using emptiness as the base, compute a common
    version and use it as input to 'merge' program.
    
    This would show the resulting (still conflicting) file left in
    the working tree as:
    
    	common file contents...
    	<<<<<< FILENAME
    	version from our branch...
    	======
    	version from their branch...
    	>>>>>> .merge_file_XXXXXX
    	more common file contents...
    
    when both sides added similar contents.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
  3. merge with /dev/null as base, instead of punting O==empty case

    Instead of leaving the path unmerged in a case where each side
    adds different version of the same path, attempt to merge it
    with empty base and leave "our" version in the index file, just
    like we do for the case in conflicting merge.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Sep 08, 2005

  1. Big tool rename.

    As promised, this is the "big tool rename" patch.  The primary differences
    since 0.99.6 are:
    
      (1) git-*-script are no more.  The commands installed do not
          have any such suffix so users do not have to remember if
          something is implemented as a shell script or not.
    
      (2) Many command names with 'cache' in them are renamed with
          'index' if that is what they mean.
    
    There are backward compatibility symblic links so that you and
    Porcelains can keep using the old names, but the backward
    compatibility support  is expected to be removed in the near
    future.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
Something went wrong with that request. Please try again.