Permalink
Commits on Aug 25, 2005
  1. Merge refs/heads/master from .

    Junio C Hamano committed Aug 25, 2005
  2. [PATCH] Fix silly pathspec bug in git-ls-files

    The "verify_pathspec()" function doesn't test for ending NUL character in
    the pathspec, causing some really funky and unexpected behaviour. It just
    happened to work in the cases I had tested.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Linus Torvalds committed with Junio C Hamano Aug 24, 2005
  3. [PATCH] Fix git-checkout-script exit status

    Sometimes the git-read-tree in git-checkout-script fails for me.
    Make sure that the failed status is passed up to caller.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    tony.luck@intel.com committed with Junio C Hamano Aug 23, 2005
  4. Merge refs/heads/master from .

    Junio C Hamano committed Aug 25, 2005
  5. Fix markup minimally to get man pages built.

    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 25, 2005
Commits on Aug 24, 2005
  1. Merge refs/heads/master from .

    Junio C Hamano committed Aug 24, 2005
  2. Update tutorial to describe shared repository style a bit more.

    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  3. Documentation: multi-head fetch.

    Add documentation related to multi-head work, including $GIT_DIR/remotes/
    changes.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  4. Support +<src>:<dst> format in push as well.

    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  5. [PATCH] Allow "+remote:local" refspec to cause --force when fetching.

    With this we could say:
    
        Pull: master:ko-master +pu:ko-pu
    
    to mean "fast forward ko-master with master, overwrite ko-pu with pu",
    and the latter one does not require the remote "pu" to be descendant
    of local "ko-pu".
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  6. [PATCH] Use git-octopus when pulling more than one heads.

    With this, you can finally say "git pull jgarzik sil24 pdc2027x".
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  7. [PATCH] "git fetch --force".

    Just like "git push" can forcibly update a ref to a value that is not
    a fast-forward, teach "git fetch" to do so as well.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  8. [PATCH] Use .git/remote/origin, not .git/branches/origin.

    Now multi-head fetch is complete, let's migrate the
    default configuration for new repositories created with
    the "git clone" command.
    
    The original $GIT_DIR/branches is not deprecated yet, but create
    remotes directory by default from the templates as well.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 20, 2005
  9. [PATCH] Make "git pull" and "git fetch" default to origin

    Amos Waterland sent in a patch for the pre-multi-head aware
    version of "git pull" to do this, but the code changed quite a
    bit since then.  If there is no argument given to pull from, and
    if "origin" makes sense, default to fetch/pull from "origin"
    instead of barfing.
    
    [jc: besides, the patch by Amos broke the non-default case where
    explicit refspecs are specified, and did not make sure we know
    what "origin" means before defaulting to it.]
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 20, 2005
  10. [PATCH] Infamous 'octopus merge'

    This script uses the list of heads and their origin multi-head "git
    fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
    merge on top of the current HEAD using them.
    
    The implementation tries to be strict for the sake of safety.  It
    insists that your working tree is clean (no local changes) and matches
    the HEAD, and when any of the merged heads does not automerge, the
    whole process is aborted and tries to rewind your working tree is to
    the original state.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 20, 2005
  11. [PATCH] Retire git-parse-remote.

    Update git-pull to match updated git-fetch and allow pull to
    fetch from multiple remote references.  There is no support for
    resolving more than two heads, which will be done with "git
    octopus".
    
    Update "git ls-remote" to use git-parse-remote-script.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 20, 2005
  12. [PATCH] Multi-head fetch.

    Traditionally, fetch takes these forms:
    
        $ git fetch <remote>
        $ git fetch <remote> <head>
        $ git fetch <remote> tag <tag>
    
    This patch updates it to take
    
        $ git fetch <remote> <refspec>...
    
    where:
    
        - A <refspec> of form "<src>:<dst>" is to fetch the objects
          needed for the remote ref that matches <src>, and if <dst>
          is not empty, store it as a local <dst>.
    
        - "tag" followed by <next> is just an old way of saying
          "refs/tags/<next>:refs/tags/<next>"; this mimics the
          current behaviour of the third form above and means "fetch
          that tag and store it under the same name".
    
        - A single token <refspec> without colon is a shorthand for
          "<refspec>:"  That is, "fetch that ref but do not store
          anywhere".
    
        - when there is no <refspec> specified
    
          - if <remote> is the name of a file under $GIT_DIR/remotes/
    	(i.e. a new-style shorthand), then it is the same as giving
    	the <refspec>s listed on Pull: line in that file.
    
          - if <remote> is the name of a file under $GIT_DIR/branches/
    	(i.e. an old-style shorthand, without trailing path), then it
    	is the same as giving a single <refspec>
    	"<remote-name>:refs/heads/<remote>" on the command line, where
    	<remote-name> is the remote branch name (defaults to HEAD, but
    	can be overridden by .git/branches/<remote> file having the
    	URL fragment notation).  That is, "fetch that branch head and
    	store it in refs/heads/<remote>".
    
          - otherwise, it is the same as giving a single <refspec>
            that is "HEAD:".
    
    The SHA1 object names of fetched refs are stored in FETCH_HEAD,
    one name per line, with a comment to describe where it came from.
    This is later used by "git resolve" and "git octopus".
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 20, 2005
  13. [PATCH] Start adding the $GIT_DIR/remotes/ support.

    All the necessary parsing code is in git-parse-remote-script;
    update git-push-script to use it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 20, 2005
  14. [PATCH] Fix "prefix" mixup in git-rev-list

    Recent changes in git have broken cg-log.  git-rev-list no longer
    prints "commit" in front of commit hashes.  It turn out a local
    "prefix" variable in main() shadows a file-scoped "prefix" variable.
    
    The patch removed the local "prefix" variable since its value is never
    used (in the intended way, that is).  The call to
    setup_git_directory() is kept since it has useful side effects.
    
    The file-scoped "prefix" variable is renamed to "commit_prefix" just
    in case someone reintroduces "prefix" to hold the return value of
    setup_git_directory().
    
    Signed-off-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    proski committed with Junio C Hamano Aug 24, 2005
  15. Audit rev-parse users again.

    Some callers to rev-parse were using the output selection flags
    inconsistently.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  16. Rationalize output selection in rev-parse.

    Earlier rounds broke 'whatchanged -p'.  In attempting to fix this,
    make two axis of output selection in rev-parse orthogonal:
    
      --revs-only	tells it not to output things that are not revisions nor
    		flags that rev-list would take.
      --no-revs	tells it not to output things that are revisions or
    		flags that rev-list would take.
      --flags	tells it not to output parameters that do not start with
    		a '-'.
      --no-flags	tells it not to output parameters that starts with a '-'.
    
    So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
    while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'.
    
    Also the meaning of --verify has been made stronger.  It now rejects
    anything but a single valid rev argument.  Earlier it passed some flags
    through without complaining.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  17. Generate pack info file after repack.

    Pulling from a packed repository over dumb transport without the
    server info file fails, so run update-server-info automatically
    after a repack by default.  This can be disabled with the '-n'
    flag.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  18. Merge refs/heads/master from .

    Junio C Hamano committed Aug 24, 2005
  19. Link the tutorial from the main document.

    And lead the reader to it at the beginning of the manual.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
  20. Try to find the optimum merge base while resolving.

    The merge-base command acquires a new option, '--all', that causes it
    to output all the common ancestor candidates.  The "git resolve"
    command then uses it to pick the optimum merge base by picking the one
    that results in the smallest number of nontrivial merges.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 24, 2005
Commits on Aug 23, 2005
  1. Merge refs/heads/master from .

    Junio C Hamano committed Aug 23, 2005
  2. Tutorial updates.

     - Use "working tree", "object name", "repository" as the canonical
       term consistenly.
    
     - Start formatting tutorial with asciidoc.
    
     - Mention shared repository style of cooperation.
    
     - Update with some usability enhancements recently made, such as
       the "-m" flag to the "git commit" command.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  3. Update git-diff-script.

    This uses the fixed rev-parse to allow passing diff options to the
    underlying diff command.  For example:
    
        $ git diff -r HEAD
    
    shows the output in raw-diff format, and
    
        $ git diff -p -R HEAD | git apply
    
    generates a patch to go back from your working tree to HEAD commit
    (i.e. an expensive way to say "git checkout -f HEAD").
    
    At the same time, it accidentally removes the use of shell arrays.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  4. Make "git-rev-list" work within subdirectories

    This trivial patch makes "git-rev-list" able to handle not being in
    the top-level directory.  This magically also makes "git-whatchanged"
    do the right thing.
    
    Trivial scripting fix to make sure that "git log" also works.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Linus Torvalds committed with Junio C Hamano Aug 23, 2005
  5. [PATCH] Fix git-rev-parse --default and --flags handling

    This makes the argument to --default and any --flags arguments should up 
    correctly, and makes "--" together with --flags act sanely.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Linus Torvalds committed with Junio C Hamano Aug 23, 2005
  6. Add placeholders for missing documents.

    The text does not say anything interesting, but at least the
    author list should reflect something close to reality.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  7. Merge refs/heads/master from .

    Junio C Hamano committed Aug 23, 2005
  8. Introduce "reset type" flag to "git reset"

    I have been feeling that the current behaviour of "git reset" is
    not quite optimal, but so far could not express exactly what I
    felt was wrong with it.  This patch clarifies it.
    
    There are at least two situations you may want to "reset" your
    working tree.
    
    1. You made a mess in your working tree.  You want to switch
       back to a known good state and start over.  This mess may be
       a result of your own editing, a merge that had too many
       conflicting changes that you do not feel like to resolve by
       hand at this moment, or a botched application of a patch you
       received from somewhere.
    
       In this case, you would want to have "git reset HEAD" reset
       the index file to the tree read from the HEAD commit and the
       files in the working tree to match index (i.e. "git status"
       should say "Nothing to commit", without any "unrecorded
       changes").
    
       The current behaviour leaves the files in the working tree
       intact, which requires you to run "git checkout -f".  Also
       you need to remember "rm -f" any files that the botched patch
       may have left in the working tree if the purpose of this
       "reset" is to attempt to apply it again; most likely the
       patch would fail if such a file is left behind.
    
    2. You have discovered that commits you made earlier need to be
       reorganized.  The simplest example is to undo the last
       commit, re-edit some files, and redo the commit.  Another
       simple eample is to undo the last two commits, and commit the
       changes in those two commits as a single commit.
    
       In this case, you would want to have "git reset HEAD^" reset
       the $GIT_DIR/HEAD to the commit object name of the parent
       commit of the current commit (i.e. rewinding one commit),
       leave the index file and the files in the working tree in a
       state where you can easily make a commit that records a tree
       that resembles what you have in the current index file and
       the working tree.
    
       The current behaviour is almost OK for this purpose, except
       that you need to find which files you need to manually run
       "git add" yourself.  They are files that are in the original
       HEAD commit and not in the commit you are resetting to.
    
    The default without the type flag is to do "--mixed", which is
    the current behaviour.
    
        $ git reset [ --hard | --soft | --mixed ] [ <commit-ish> ]
    
    A hard reset would be used for 1 and works in this way:
    
        (1) remember the set of paths that appear in the current
            index file (which may even have unmerged entries) and
    	the current $GIT_DIR/HEAD commit.
    
        (2) "read-tree --reset" the specified <commit-ish> (default
            to HEAD), followed by "checkout-cache -f -u -a".
    
        (3) remove any files that appear in (1) but not in
            <commit-ish> from the working tree.
    
        (4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
            $GIT_DIR/HEAD with the specified <commit-ish>.
    
        (5) remove leftover $GIT_DIR/MERGE_HEAD
    
    A soft reset would be used for 2 and works in this way:
    
        (1) Make sure that the index file is merged and we do not
            have MERGE_HEAD; otherwise it does not make sense to do
            soft reset.
    
        (2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
            $GIT_DIR/HEAD with the specified <commit-ish>.
    
    Note that with the current behaviour, "git diff" is the way to
    see what could be committed immediately after "git reset".  With
    the "soft reset" described here you would need to say "git diff
    HEAD" to find that out.
    
    I am not sure what mixed reset (the current behaviour) is good
    for.  If nobody comes up with a good use case it may not be a
    bad idea to remove it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  9. Clean-up output from "git show-branch" and document it.

    When showing only one branch a lot of default output becomes redundant,
    so clean it up a bit, and document what is shown.  Retire the earlier
    implementation "git-show-branches-script".
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 23, 2005
  10. [PATCH] Add 'git show-branch'.

    The 'git show-branches' command turns out to be reasonably useful,
    but painfully slow.  So rewrite it in C, using ideas from merge-base
    while enhancing it a bit more.
    
     - Unlike show-branches, it can take --heads (show me all my
       heads), --tags (show me all my tags), or --all (both).
    
     - It can take --more=<number> to show beyond the merge-base.
    
     - It shows the short name for each commit in the extended SHA1
       syntax.
    
     - It can find merge-base for more than two heads.
    
    Examples:
    
        $ git show-branch --more=6 HEAD
    
        is almost the same as "git log --pretty=oneline --max-count=6".
    
        $ git show-branch --merge-base master mhf misc
    
        finds the merge base of the three given heads.
    
        $ git show-branch master mhf misc
    
        shows logs from the top of these three branch heads, up to their
        common ancestor commit is shown.
    
        $ git show-branch --all --more=10
    
        is poor-man's gitk, showing all the tags and heads, and
        going back 10 commits beyond the merge base of those refs.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano committed Aug 21, 2005