GIT 0.99.7d, and end of week status.

GIT 0.99.7d, and end of week status.

[Junio C Hamano]

* The fourth minor fix release, GIT 0.99.7d, is available at the
  usual places.

  RPMs and Debs are found in http://kernel.org/pub/software/scm/

  With git:

  $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d
  $ git checkout -b <new-branch> v0.99.7d

  Fixes since 0.99.7c are:

  - Fix show-branch output that named commits incorrectly.
  - Fix git-grep -e not passing -e to underlying grep.

* Recent updates to the master branch includes:

  - The GIT_VERSION is now 0.99.7.GIT (thanks Pasky for the
    idea).

  - The symlinks for backward compatible names are not installed
    anymore (but existing ones are not automatically removed).

  - git-diff-* family acquired a new option, --name-status, to
    show the status and name for changed files.  Also -l<num>
    option disables rename/copy detection when the number of
    rename target candidates are more than <num> (idea by Linus
    some time ago).

* Proposed updates, not yet graduated to the master branch
  includes:

  - git-merge fix, not to require a clean tree.

  - Likewise for git-revert and git-cherry-pick fix, not to
    require a clean tree.

  - Use git-merge from git-pull, again.

  - A couple of test fixes for further Solaris portability.

  - update-index takes -z --stdin to read NUL terminated list of
    paths from the standard input instead of from the command
    line.  This is to help platforms with xargs that cannot grok
    -0.  git-commit is updated to use this.

Re: GIT 0.99.7d, and end of week status.

[Alan Chandler]

On Sunday 25 Sep 2005 09:36, Junio C Hamano wrote:
> * The fourth minor fix release, GIT 0.99.7d, is available at the
>   usual places.

I can't find it.  Is this a propogation timing issue?

I tried both ip addresses quoted as being kernel.org




-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

I said:

> * The fourth minor fix release, GIT 0.99.7d, is available at the
>   usual places.
>
>   With git:
>
>   $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d
>   $ git checkout -b <new-branch> v0.99.7d

If you pick a suitable name as <new-branch> that the repository
in which you keep track git.git does not yet have, "maint997" for
example, and if your working tree is identical to whatever your
HEAD happens to be, then the above instruction should be read as:

    $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d
    $ git checkout -b maint997 v0.99.7d

and that would give you the exact contents of v0.99.7d in your
working tree.

But this was really a stupid way to give instructions, and would
probably have caused confusion.  Sorry about that, if you were
one of the people who were bitten.

I deliberately did not say:

    $ git pull http://kernel.org/pub/scm/git/git.git tag v0.99.7d

because the result would be affected by whatever the random
state the repository was in.

Folks using CVS seem to announce "A new release is available and
tagged as r0.99.7d", people seem to know what they need to do
when seeing that announcement ("cvs update -r r0.99.7d"), and
this command line, as long as the working tree tracks that
remote project CVS repository, would give more-or-less the same
result for everyone no matter what the original state of the
working tree was.  GIT is a bit different in that branch names
are local and you do not really "check out a tag".

One straightforward way which would work for everybody would be
(provided you do not have git-src in the current directory):

   $ git clone http://kernel.org/pub/scm/git/git.git git-src
   $ cd git-src
   $ git reset --hard v0.99.7d

This will give all the public branches and tags (renaming of
public "master" to "origin" is done by "git clone"), and match
your "master" to "v0.99.7d".

When you already have a repository to track git.git, I would
recommend to have something like this in .git/remote/origin:

    URL: http://kernel.org/pub/scm/git/git.git
    Pull: master:origin maint:maint +pu:pu

Then you can say:

    $ git fetch origin tag v0.99.7d

This only updates your .git/refs/tags/v0.99.7d and downloads
necessary objects.  To see them in your working tree (e.g. for
compilation), you would need to check it out.

Now, how would you check out the v0.99.7d tag?  There are two
ways to think about it.

If the reason you want v0.99.7d, not "master" nor "pu", is you
would want to stay with the 0.99.7 but get all the latest safer
fixes, then you can just checkout "maint" branch instead, like
this:

    $ git checkout -f maint

This will get you everything in the maintenance branch and may
contain fixes that happened after v0.99.7d -- you are taking my
0.99.7d announce as just a hint to say: "Junio has accumulated
enough maintenance fixes in the maint branch and tagged its tip".

And the announcement is just that.  I try to make sure that what
are in the maint branch are just "safer fixes that do not break
existing setup", but I do not do any more special testing than
what I already do to make commits into the maint branch when I
tag the tip of it.  In other words, the one that happens to be
tagged as 0.99.7d is not any safer than the next commit that
comes on the maint branch (there is none at this moment).  The
later tip of the maint branch had better be more correct than
v0.99.7d -- that is what "fix" usually means ;-).

On the other hand, if the reason you want v0.99.7d is to point
out things broke at that exact commit, you would need to check
out that exact version, not just a random commit that happens to
be at the tip of maint.  And you need a branch to check it out
onto in that case.  Assuming that you do not have a branch
called "throwaway":

    $ git checkout -f -b throwaway v0.99.7d

would give you the working tree that matches what is in v0.99.7d
and a new branch "throwaway" whose tip is the commit tagged as
v0.99.7d.  The usual caveat applies: if your working tree and
index had changes since the HEAD commit you had before you did
the above checkout, that change may be lost with '-f' flag.  But
the point of this checkout is to get what is in the named tag
exactly, you would want to lose them -- otherwise make a commit
to your branch, or stash away 'git diff HEAD' output, before
doing the checkout.

After that, if you want to see what v0.99.7c used to do, you
could (still remaining on the "throwaway" branch):

    $ git reset --hard v0.99.7c

[jc: maybe somebody can send a patch to add the later part of
this message as Documentation/howto/checking-out-a-tag.txt ].

Re: GIT 0.99.7d, and end of week status.

[Alan Chandler]

On Sunday 25 Sep 2005 19:47, Junio C Hamano wrote:
...
>
> One straightforward way which would work for everybody would be
> (provided you do not have git-src in the current directory):
>
>    $ git clone http://kernel.org/pub/scm/git/git.git git-src
>    $ cd git-src

I did the above just after your announcement but before the tags etc had got 
there (see my earlier question in this thread).


>    $ git reset --hard v0.99.7d

Didn't do this
...
> Then you can say:
>
>     $ git fetch origin tag v0.99.7d
 Did this
...
> Now, how would you check out the v0.99.7d tag?  There are two
> ways to think about it.
>
> If the reason you want v0.99.7d, not "master" nor "pu", is you
> would want to stay with the 0.99.7 but get all the latest safer
> fixes, then you can just checkout "maint" branch instead, like
> this:
>
>     $ git checkout -f maint
>

I am rather new to all this, but this last step puzzles me.

Before this step, and using gitk --all, I can see the maintenance branch, but 
its currently connected to the point where the v0.99.7c tag is and not where 
your latest tag is.

So if I followed these instructions, now, wouldn't I just get the v0.997c tag?

Does that mean I have missed some step along the way to get the maint branch 
position moved to the new tag?


-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: GIT 0.99.7d, and end of week status.

[Tom Prince]

Junio C Hamano <junkio@cox.net> writes:

>
> When you already have a repository to track git.git, I would
> recommend to have something like this in .git/remote/origin:
>
>     URL: http://kernel.org/pub/scm/git/git.git
>     Pull: master:origin maint:maint +pu:pu
>

A warning when you do this. If you say 

  git pull origin

then your master will be updated with an octopus merge of the three heads.

  Tom

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

Tom Prince <tom.prince@ualberta.net> writes:

>> When you already have a repository to track git.git, I would
>> recommend to have something like this in .git/remote/origin:
>>
>>     URL: http://kernel.org/pub/scm/git/git.git
>>     Pull: master:origin maint:maint +pu:pu
>>
>
> A warning when you do this. If you say 
>
>   git pull origin
>
> then your master will be updated with an octopus merge of the three heads.

Ahhhhhhhh.  That is true.  I always do "git fetch" and never do
"git pull" against anything but a local repository, heads
explicitly specified.  You are right.  The defaulting behaviour
is incredibly broken.

Do people agree it is a good idea to change the "git pull
origin" to mean "fetch all the default refs specified on Pull:
lines, and merge only the first one into the current branch"?

"git pull" without remote nor refspecs is a synonym to "git pull
origin" as before, and 99.99% of the time "git pull" from a
remote repo without explicit refspec is doing just one head
merge, so I think this is a sane default, much saner than the
current mess, while still allowing you to keep track of what's
happening in the other branches by doing fetches of all the
heads at once.

Opinions?

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> Does that mean I have missed some step along the way to get the maint branch 
> position moved to the new tag?

To recap, you did:

    (before 0.99.7d propagated to the mirrors)
    $ git clone http://kernel.org/pub/scm/git/git.git git-src
    $ cd git-src

    (after 0.99.7d propagated to the mirrors)
    $ git fetch origin tag v0.99.7d
    $ git checkout -f maint

The 'fetch origin tag v0.99.7d' step should have left
the new file .git/refs/tags/v0.99.7d _after_ downloading all the
objects necessary to reconstruct the history to get there.  

Ah, you are right.  My instruction did not update other branches
for you.  My bad.

Assuming people stay on their "master" branch, and have the
recommended .git/remotes/origin contents in my previous message,
then the steps "after 0.99.7d propagated to the mirrors" would
just be:

    $ git fetch

which would fetch all the branches mentioned in the remotes
file, and then:

    $ git checkout -f maint

which would switch your working tree to maint branch.

NOTE NOTE NOTE.  The above assumes you are on your "master"
branch when you run 'git fetch' --- if you are on any of the
branches that is being updated (you can check which branch you
are on with 'git branch' without argument, or just with 'ls -l
.git/HEAD') 'git fetch' will complain because doing so without
updating them to match the updated branch head would make your
index file and working tree inconsistent with your .git/HEAD,
but 'git fetch' is supposed to be only fetching without touching
the working tree.

Re: GIT 0.99.7d, and end of week status.

[Alan Chandler]

On Monday 26 Sep 2005 01:01, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> > Does that mean I have missed some step along the way to get the maint
> > branch position moved to the new tag?
>
> To recap, you did:
>
>     (before 0.99.7d propagated to the mirrors)
>     $ git clone http://kernel.org/pub/scm/git/git.git git-src
>     $ cd git-src
>
>     (after 0.99.7d propagated to the mirrors)
>     $ git fetch origin tag v0.99.7d
>     $ git checkout -f maint

Actually, I got as far as doing the fetch, but I didn't checkout anything.  I 
just ran gitk --all 

I would have been on the branch that the git clone would have left me on 
(presumably master)

>
> The 'fetch origin tag v0.99.7d' step should have left
> the new file .git/refs/tags/v0.99.7d _after_ downloading all the
> objects necessary to reconstruct the history to get there.
>

Yes - I gitk showed had all the objects - but v0.99.7d was a a tag at the tip 
of an unamed branch

> Ah, you are right.  My instruction did not update other branches
> for you.  My bad.
>
> Assuming people stay on their "master" branch, and have the
> recommended .git/remotes/origin contents in my previous message,
> then the steps "after 0.99.7d propagated to the mirrors" would
> just be:
>
>     $ git fetch

Its not the "other" branches that I was concerned about, it was the "maint" 
branch reference which seemed to still be still at the same commit as the 
v0.99.7c tag, at least that was what gitk --all showed me, after the fetch. 


>
> which would fetch all the branches mentioned in the remotes
> file, and then:
>
>     $ git checkout -f maint

This is where I get puzzled.  Fetch on its own didn't move where "maint" 
pointed to so doing this checkout would have left me at the v0.99.7c tag (I 
didn't actually do it - as I was then puzzling over the documentation trying 
to see what I did wrong)

I realise I could have just manually moved it - but none of the steps in your 
instructions seemed to move it for me.

In the end - I blew my git away and repeated the clone exercise after the 
mirrors had updated - in this version the "maint" branch was co-incident with 
the v0.99.7d tag

>
> which would switch your working tree to maint branch.
>
> NOTE NOTE NOTE.  The above assumes you are on your "master"
> branch when you run 'git fetch' --- if you are on any of the
> branches that is being updated (you can check which branch you
> are on with 'git branch' without argument, or just with 'ls -l
> .git/HEAD') 'git fetch' will complain because doing so without
> updating them to match the updated branch head would make your
> index file and working tree inconsistent with your .git/HEAD,
> but 'git fetch' is supposed to be only fetching without touching
> the working tree.



-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: GIT 0.99.7d, and end of week status.

[Petr Baudis]

Dear diary, on Mon, Sep 26, 2005 at 01:46:13AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Tom Prince <tom.prince@ualberta.net> writes:
> 
> >> When you already have a repository to track git.git, I would
> >> recommend to have something like this in .git/remote/origin:
> >>
> >>     URL: http://kernel.org/pub/scm/git/git.git
> >>     Pull: master:origin maint:maint +pu:pu
> >>
> >
> > A warning when you do this. If you say 
> >
> >   git pull origin
> >
> > then your master will be updated with an octopus merge of the three heads.
> 
> Ahhhhhhhh.  That is true.  I always do "git fetch" and never do
> "git pull" against anything but a local repository, heads
> explicitly specified.  You are right.  The defaulting behaviour
> is incredibly broken.
> 
> Do people agree it is a good idea to change the "git pull
> origin" to mean "fetch all the default refs specified on Pull:
> lines, and merge only the first one into the current branch"?

I don't like that, the notion that you are fetching different stuff that
you are merging then seems quite confusing to me. But fetching just the
first revision will be confusing too. Either way, git-pull won't be
equivalent to git-fetch && git-merge (or git-resolve or whatever is the
core porcelain command) anymore. Well, the remotes stuff never got close
to my heart.

One alternative I can think of is, in case there are multiple heads,
require the user to explicitly specify the head he wants (origin#maint).
This comes from the idea that multi-head remotes are there really
primarily for fetching, not for pulling. There is also no potential for
confusion. In addition, there might another line "Default" in the remote
file, which could specify the default choice. It's just that choosing
the first one implicitly makes me a bit nervous and has potential for
bad mistakes. At least for Cogito, I would be reluctant to use it.

git-pull --merge-all or something to still do the octopus merge might be
useful in some cases (or as well might not - perhaps the best strategy
is to let whoever cares make a patch ;).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: GIT 0.99.7d, and end of week status.

[Jon Loeliger]

On Sun, 2005-09-25 at 18:46, Junio C Hamano wrote:
> Tom Prince <tom.prince@ualberta.net> writes:
> 
> >> When you already have a repository to track git.git, I would
> >> recommend to have something like this in .git/remote/origin:
> >>
> >>     URL: http://kernel.org/pub/scm/git/git.git
> >>     Pull: master:origin maint:maint +pu:pu
> >>
> >
> > A warning when you do this. If you say 
> >
> >   git pull origin
> >
> > then your master will be updated with an octopus merge of the three heads.
> 
> Ahhhhhhhh.  That is true.  I always do "git fetch" and never do
> "git pull" against anything but a local repository, heads
> explicitly specified.  You are right.  The defaulting behaviour
> is incredibly broken.
> 
> Do people agree it is a good idea to change the "git pull
> origin" to mean "fetch all the default refs specified on Pull:
> lines, and merge only the first one into the current branch"?
> 
> "git pull" without remote nor refspecs is a synonym to "git pull
> origin" as before, and 99.99% of the time "git pull" from a
> remote repo without explicit refspec is doing just one head
> merge, so I think this is a sane default, much saner than the
> current mess, while still allowing you to keep track of what's
> happening in the other branches by doing fetches of all the
> heads at once.
> 
> Opinions?

Hmmm...  Would it make sense to introduce something
like this instead:

    # When fetching, get bits from here:
    URL: http://...../git.git
    # When fetching, grab and map like this:
    Fetch: master:origin maint:maint +pu:pu
    # When merging, merge origin, maint and pu into master
    Merge: master origin maint pu

With the intent that the "Fetch:" line effectively
limits the fetching operation to git-fetch, and doesn't
specify how to merge.  Then, the "Merge:" line specifies
how to do the git-merge bits.  If you didn't want to
merge in the maint and pu bits, this would have been
the line instead:

    # Merge into master the just the origin bits
    Merge: master origin

If you want the dual-step fetch+merge, the leave the "Pull:"
line as originally written:

    # Fetch and merge
    Pull: master:origin maint:maint +pu:pu

Syntax can be argued, of course.  My point being to
introduce another line to the remote file that
distinguishes the default behavior for each step
along the way.

Thanks,
jdl

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

> This is where I get puzzled.  Fetch on its own didn't move where "maint" 
> pointed to so doing this checkout would have left me at the v0.99.7c tag (I 
> didn't actually do it - as I was then puzzling over the documentation trying 
> to see what I did wrong)

Because "git fetch origin tag v0.99.7d" fetched only that tag --
git-fetch command is not told to fetch anything else.  Most
importantly, it did not tell it to update "maint" branch head
from the remote.  That was why I said that instrucition was
busted.

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> ... Either way, git-pull won't be equivalent to git-fetch &&
> git-merge (or git-resolve or whatever is the core porcelain
> command) anymore.

"pull = fetch + merge" is a reasonable approximation to use when
you explain what they are to somebody, but taking it literally
would harm usefulness.

It is what you have already lived with for a while.  "git pull
.../linux/2.6.git v2.6.11-tree v2.6.12" would fetch both heads
but merges v2.6.12 head only (because v2.6.11-tree is not
something you can merge with).

The typical use cases are:

 - The remote does not have more than one head (majority of the
   kernel.org repositories are single head repositories).  You
   could say "Pull: master:somebody" in .git/remotes/somebody
   and say "git pull somebody" and pull is fetch + merge.  The
   proposed fix does not affect this case.

 - The remote has more than one heads, and they are usually both
   interesting.  Some kernel.org repositories have release and
   test heads and people who are interested in what is happening
   in that subsystem are likely to want to inspect both, so
   fetching both makes a lot of sense (especially given
   multi-head fetch over git-native protocol is more efficieint
   than fetching them separately), but obviously merging both
   into an Octopus does not make any sense most of the time.

   You could say "Pull: release:a/release test:a/test" in
   .git/remotes/subsys and "git fetch subsys" would fetch both
   and store them locally.  "git pull subsys" would fetch both
   but merges only subs/release, which is far more useful than
   attempting to make an Octopus with both heads.  You could
   still say "git pull subsys test" to only fetch and merge
   test, if you needed to do something different from what the
   "merge only the first one by default" rule gives.

 - The remote has 47 different heads, and they are more or less
   independent developments in the same area ("topic branches").
   Jeff's libata-dev repository may be a good example.  "Pull:
   ALL:libata-dev/ALL ncq:libata-dev/ncq
   chs-support:libata-dev/chs-support ..."  would be what one
   would place in .git/remotes/libata-dev.  This list can be a
   subset of the heads that exist at remote but only the heads
   one is interested in.  "git fetch libata-dev" would get all
   the heads in that repository one is interested in, "git pull
   libata-dev" would merge in ALL (which is premerged at the
   remote side) thanks to the "merge only first one by default"
   rule.  If you want to make Octopus with selected heads (not
   the one Jeff made in ALL), you still can say "git pull
   libata-dev ncq chs-support" to do so.

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

Jon Loeliger <jdl@freescale.com> writes:

There is a small problem in that proposal.  "Merging" in git
does not work that way.  Specifically,

>     # When merging, merge origin, maint and pu into master
>     Merge: master origin maint pu
>     # Merge into master the just the origin bits
>     Merge: master origin

the problem with these is that you may be in your "test" branch
and say "git pull".  'git pull' does not let you say 'pull into
this branch which is not my current branch', and "into master"
part would not work -- merge in git always merges things into
the current branch, so writing

>     # When merging, merge origin, maint and pu into the current
>     Merge: origin maint pu
>     # Merge just the origin bits into the current
>     Merge: origin

may make sense.

Having said that I doubt Octopus is what people do regularly, so
being able to write "Merge: origin maint pu" (or "Merge: ncq
chs-support") as a short-hand makes much sense.

There is not much inherent reason to require that the merge
happens only to the current branch, if we stop using the files
in the working tree for resolving conflicts (either manually or
automatically).  We could rewrite 'git pull' like this:

 - have it take 'merge into this branch' parameter, defaulting
   to the current branch, or your "Merge: <into> <remote>..."
   proposal.

 - if the merge is not to happen in the current branch, then
   use a temporary index file and a temporary working directory
   to do the merge -- when manual conflict resolution is needed,
   ask the user to go to that temporary working directory and
   resolve conflicts there and make commits there.  The
   temporary working directory is actually cheap because we do
   not have to checkout all the paths -- only the paths involved
   in the merge.

I remember the merge Linus originally envisioned would have
worked along the above lines, until he changed his mind around
2a68a8659f7dc55fd285d235ae2d19e7a8116c30 commit, beginning of
June, for 1.0 (ewww, we were already aiming for 1.0 back then).

	http://marc.theaimsgroup.com/?l=git&m=111806925225305&w=2

declared the merge in separate directory is post 1.0 item, and I
tend to agree with that.  Most of the time you will be merging
into the current branch, and otherwise you could make it so by
switching to that branch before pulling.

[PATCH] Fix default pull not to do an unintended Octopus.

[Junio C Hamano]

This is what I ended up doing Sunday night before the discussion
started, and what I still have in the proposed updates branch.

It implements the 'when puling using a shorthand without
explicitly telling which refs to pull, only use the first ref
found from Pull: lines for merging -- creating Octopus using all
default refs is not useful 99.99% of the time' behaviour I
outlined yesterday.

I think it could be modified without too much pain to take
"which heads to use for merge by default" information from
separate "Merge: " line as Jon proposed, if enough people like
that idea better.  Personally I do not think it would make much
practical difference from the end users' point of view, but I've
been proven wrong more often than not in the past, so...

As Pasky said in another thread, git-fetch is not the most
elegantly written script on earth, and it is not my favorite
script either -- it needs to do complex things, like interacting
with the later git-pull stage.

------------
The refspecs specified in the .git/remotes/<remote> on the "Pull: "
lines are for fetching multiple heads in one go, but most of the time
making an Octopus out of them is not what is wanted.  Make git-fetch
leave the marker in .git/FETCH_HEAD file so that later stages can
tell which heads are for merging and which are not.

Tom Prince made me realize how stupid the original behaviour was.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 git-fetch.sh           |   32 ++++++++++++++++++++++++++++----
 git-fmt-merge-msg.perl |    4 +++-
 git-parse-remote.sh    |   11 +++++++++--
 git-pull.sh            |    4 +++-
 4 files changed, 43 insertions(+), 8 deletions(-)

44dbc712fe3dd045550123e1cc689c41482c62e5
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -54,6 +54,10 @@ append_fetch_head () {
     remote_name_="$3"
     remote_nick_="$4"
     local_name_="$5"
+    case "$6" in
+    t) not_for_merge_='not-for-merge' ;;
+    '') not_for_merge_= ;;
+    esac
 
     # remote-nick is the URL given on the command line (or a shorthand)
     # remote-name is the $GIT_DIR relative refs/ path we computed
@@ -78,10 +82,11 @@ append_fetch_head () {
     if git-cat-file commit "$head_" >/dev/null 2>&1
     then
 	headc_=$(git-rev-parse --verify "$head_^0") || exit
-	echo "$headc_	$note_" >>$GIT_DIR/FETCH_HEAD
+	echo "$headc_	$not_for_merge_	$note_" >>$GIT_DIR/FETCH_HEAD
 	echo >&2 "* committish: $head_"
 	echo >&2 "  $note_"
     else
+	echo "$head_	not-for-merge	$note_" >>$GIT_DIR/FETCH_HEAD
 	echo >&2 "* non-commit: $head_"
 	echo >&2 "  $note_"
     fi
@@ -157,6 +162,13 @@ do
 
     # These are relative path from $GIT_DIR, typically starting at refs/
     # but may be HEAD
+    if expr "$ref" : '\.' >/dev/null
+    then
+	not_for_merge=t
+	ref=$(expr "$ref" : '\.\(.*\)')
+    else
+	not_for_merge=
+    fi
     if expr "$ref" : '\+' >/dev/null
     then
 	single_force=t
@@ -216,7 +228,8 @@ do
 	continue ;;
     esac
 
-    append_fetch_head "$head" "$remote" "$remote_name" "$remote_nick" "$local_name"
+    append_fetch_head "$head" "$remote" \
+    	"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
 
 done
 
@@ -241,16 +254,27 @@ http://* | https://* | rsync://* )
 	    case "$ref" in
 	    +$remote_name:*)
 		single_force=t
+		not_for_merge=
+		found="$ref"
+		break ;;
+	    .+$remote_name:*)
+		single_force=t
+		not_for_merge=t
+		found="$ref"
+		break ;;
+	    .$remote_name:*)
+	        not_for_merge=t
 		found="$ref"
 		break ;;
 	    $remote_name:*)
+	    	not_for_merge=
 		found="$ref"
 		break ;;
 	    esac
 	done
-
 	local_name=$(expr "$found" : '[^:]*:\(.*\)')
-	append_fetch_head "$sha1" "$remote" "$remote_name" "$remote_nick" "$local_name"
+	append_fetch_head "$sha1" "$remote" \
+		"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
     done || exit
     ;;
 esac
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -31,6 +31,8 @@ while (<>) {
 	my ($bname, $tname, $gname, $src);
 	chomp;
 	s/^[0-9a-f]*	//;
+	next if (/^not-for-merge/);
+	s/^	//;
 	if (s/ of (.*)$//) {
 		$src = $1;
 	} else {
@@ -86,7 +88,7 @@ for my $src (@src) {
 			    $src{$src}{GENERIC});
 	my $this = join(', ', @this);
 	if ($src ne '.') {
-		$this .= " from $src";
+		$this .= " of $src";
 	}
 	push @msg, $this;
 }
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -65,8 +65,11 @@ get_remote_default_refs_for_push () {
 	esac
 }
 
-# Subroutine to canonicalize remote:local notation
+# Subroutine to canonicalize remote:local notation.
 canon_refs_list_for_fetch () {
+	# Leave only the first one alone; add prefix . to the rest
+	# to prevent the secondary branches to be merged by default.
+	dot_prefix=
 	for ref
 	do
 		force=
@@ -91,7 +94,8 @@ canon_refs_list_for_fetch () {
 		heads/* | tags/* ) local="refs/$local" ;;
 		*) local="refs/heads/$local" ;;
 		esac
-		echo "${force}${remote}:${local}"
+		echo "${dot_prefix}${force}${remote}:${local}"
+		dot_prefix=.
 	done
 }
 
@@ -107,6 +111,9 @@ get_remote_default_refs_for_fetch () {
 		echo "refs/heads/${remote_branch}:refs/heads/$1"
 		;;
 	remotes)
+		# This prefixes the second and later default refspecs
+		# with a '.', to signal git-fetch to mark them
+		# not-for-merge.
 		canon_refs_list_for_fetch $(sed -ne '/^Pull: */{
 						s///p
 					}' "$GIT_DIR/remotes/$1")
diff --git a/git-pull.sh b/git-pull.sh
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -24,7 +24,9 @@ then
 		die "You need to first update your working tree."
 fi
 
-merge_head=$(sed -e 's/	.*//' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ')
+merge_head=$(sed -e '/	not-for-merge	/d' \
+	-e 's/	.*//' "$GIT_DIR"/FETCH_HEAD | \
+	tr '\012' ' ')
 
 case "$merge_head" in
 '')

Re: GIT 0.99.7d, and end of week status.

[Petr Baudis]

Dear diary, on Mon, Sep 26, 2005 at 10:17:32PM CEST, I got a letter
where Jon Loeliger <jdl@freescale.com> told me that...
> Hmmm...  Would it make sense to introduce something
> like this instead:
> 
>     # When fetching, get bits from here:
>     URL: http://...../git.git
>     # When fetching, grab and map like this:
>     Fetch: master:origin maint:maint +pu:pu
>     # When merging, merge origin, maint and pu into master
>     Merge: master origin maint pu
> 
> With the intent that the "Fetch:" line effectively
> limits the fetching operation to git-fetch, and doesn't
> specify how to merge.  Then, the "Merge:" line specifies
> how to do the git-merge bits.  If you didn't want to
> merge in the maint and pu bits, this would have been
> the line instead:
> 
>     # Merge into master the just the origin bits
>     Merge: master origin
> 
> If you want the dual-step fetch+merge, the leave the "Pull:"
> line as originally written:
> 
>     # Fetch and merge
>     Pull: master:origin maint:maint +pu:pu
> 
> Syntax can be argued, of course.  My point being to
> introduce another line to the remote file that
> distinguishes the default behavior for each step
> along the way.

Yes, this is basically the idea behind my "Default" line, but arguably
nicer and more flexible. I fully agree with Junio that pulling should
merge to your current branch, but I like your idea otherwise.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH] Fix default pull not to do an unintended Octopus.

[Josef Weidendorfer]

On Tuesday 27 September 2005 09:38, Junio C Hamano wrote:
> I think it could be modified without too much pain to take
> "which heads to use for merge by default" information from
> separate "Merge: " line as Jon proposed, if enough people like
> that idea better.  Personally I do not think it would make much
> practical difference from the end users' point of view, but I've
> been proven wrong more often than not in the past, so...

Hmm...
What is the "intuitive" thing a user would expect when looking at
a remotes file? It looks like including lists of default heads which
are used for git commands when no further head is specified, i.e.
which are automatically appended to the command line.

E.g. with .git/remotes/remoterep looking like

	URL: ...
	Pull: local1:remote1 local2:remote2
	Push: local3:remote3 local4:remote4

a
	git push remoterep

expands to (AFAIK)

	git push remoterep local3:remote3 local4:remote4

So for
	git pull remoterep

the expected command seems to be

	git pull local1:remote1 local2:remote2

and of course this does an octopus merge at the end.
It may be a strange thing to do, but if the user does *not* want to do
octopus merges, he probably only will give one default head in the Pull
line of the remotes file.

So I would not change the current behavior.

It seems better to me to support an additional "Fetch:" line.
IMHO, a "Merge:" lines does not make sense, as "git merge" has
nothing to do with remote repositories at all [I just looked up
the man page of git-merge, and confusingly it talks about "remotes",
which are in fact local heads to be merged].

> As Pasky said in another thread, git-fetch is not the most
> elegantly written script on earth, and it is not my favorite
> script either -- it needs to do complex things, like interacting
> with the later git-pull stage.

Like Pasky, I am not really comfortable with this remotes stuff.
AFAIK, it was introduced to shorten some command line by providing defaults
(to be used by the "GIT core porcelain"). But I still have to provide the 
remote shortcut on the command line.

As Cogito does, I expect the porcelain to store the mapping of a
local head to a remote head, automatically using the right remote
repository.

I want to type "git fetch maint" to get the maintanance branch of
git, and not specify an additionally introduced arbitrary short name
for the remote git repo (which is used quite less often than my
head names: heads appear in gitk, I switch among heads...).
And using the same name for a remote shortcut and a local head can
confuse people.

So IMHO default actions should be stored for branches, not for shortcuts
of remote positions. The branches stuff matches this better, as one
file in branches/ corresponds exactly to one head with the same name,
and specifies the attributes "remote repository" and "remote head".

This also shortens command lines much better then the remotes stuff,
as you implicity specify a default head: The one you are on.

Perhaps we should have extended the branches file to allow different
remote reps and heads depending on the command (fetch/pull/merge/push).
A "URL:" is not needed, as you probably like to have different repos for pull 
and push. And in contrast to the remotes stuff above, a "Merge:" line makes 
quite sense here: When on "mybranch", a merge should default to merging
the heads specified on the Merge line in branches/mybranch.

When cloning a remote head, Cogito creates a local "origin" head and
corresponding mapping in branches/origin. Afterwards, it automatically
generates a new local branch "master", which branches of at the
origin. Further "cg-updates" (=git fetch+merge) fetch origin, and merge
origin into master.
I assume that this currently is hardcoded in scripts?
Shouldn't there be created a branches/master, specifying that a default
merge should happen with "origin"? This way, an "cg-update" would look
into "branches/master" on the "Merge:" line. It sees that "origin" is
bound to a remote head, and thus, does a fetch before merging.

Opinions?

Josef

Re: GIT 0.99.7d, and end of week status.

[Petr Baudis]

Dear diary, on Tue, Sep 27, 2005 at 12:03:47AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
>  - if the merge is not to happen in the current branch, then
>    use a temporary index file and a temporary working directory
>    to do the merge -- when manual conflict resolution is needed,
>    ask the user to go to that temporary working directory and
>    resolve conflicts there and make commits there.  The
>    temporary working directory is actually cheap because we do
>    not have to checkout all the paths -- only the paths involved
>    in the merge.

By the way, this is how Cogito did merging for some (rather short) time
period (actually, there's perhaps still some remnant of this, I think
Cogito still by default ignores ,,merge* which was the subdirectory
where the merge happenned). I removed it because IIRC the people weren't
eventually all that excited about it after all and Linus changed his
mind too.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: GIT 0.99.7d, and end of week status.

[Petr Baudis]

Dear diary, on Mon, Sep 26, 2005 at 10:25:28PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > ... Either way, git-pull won't be equivalent to git-fetch &&
> > git-merge (or git-resolve or whatever is the core porcelain
> > command) anymore.
> 
> "pull = fetch + merge" is a reasonable approximation to use when
> you explain what they are to somebody, but taking it literally
> would harm usefulness.
> 
> It is what you have already lived with for a while.  "git pull
> .../linux/2.6.git v2.6.11-tree v2.6.12" would fetch both heads
> but merges v2.6.12 head only (because v2.6.11-tree is not
> something you can merge with).

Yes, but that's a rather obscure case. :-) But well, your use cases
convinced me that the behaviour to fetch multiple heads even if you are
going to merge just one of them is useful enough. However, I still think
that the user should be required to specify the to-be-merged head
manually if the default choice isn't explicitly written in the remotes
file.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH] Fix default pull not to do an unintended Octopus.

[Petr Baudis]

Dear diary, on Tue, Sep 27, 2005 at 11:52:42AM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> As Cogito does, I expect the porcelain to store the mapping of a
> local head to a remote head, automatically using the right remote
> repository.

Yes. I'm actually inclined to keep this setup, simply because it is

  * easy
  * simple
  * sufficient in most of the cases

Cogito's fetch/update should certainly support the remotes stuff, since
they are obviously much more useful and practical for more complicated
setup, but I think I will keep the branches/ setup (the name of the
directory is the only thing I don't like on it ;) as the primary mean of
configuring remote branches.  I will only have to add possibility to
cg-fetch multiple branches at once, which could also make branches/
significantly more practical.

> Perhaps we should have extended the branches file to allow different
> remote reps and heads depending on the command (fetch/pull/merge/push).
> A "URL:" is not needed, as you probably like to have different repos for pull 
> and push. And in contrast to the remotes stuff above, a "Merge:" line makes 
> quite sense here: When on "mybranch", a merge should default to merging
> the heads specified on the Merge line in branches/mybranch.

No. If you are in the branches/ playground, please keep it strictly
one-to-one mapping. That's what makes it easy and simple and that's what
makes it good.

> When cloning a remote head, Cogito creates a local "origin" head and
> corresponding mapping in branches/origin. Afterwards, it automatically
> generates a new local branch "master", which branches of at the
> origin. Further "cg-updates" (=git fetch+merge) fetch origin, and merge
> origin into master.
> I assume that this currently is hardcoded in scripts?

Yes.

> Shouldn't there be created a branches/master, specifying that a default
> merge should happen with "origin"? This way, an "cg-update" would look
> into "branches/master" on the "Merge:" line. It sees that "origin" is
> bound to a remote head, and thus, does a fetch before merging.

If ever doing that, this should be done at some other place than
branches/. And I'm sceptical about it anyway. Really, introducing some
new configuration mechanism just to tell Cogito what default branch name
should it pick up when you call fetch/update/merge without a parameter?
I don't know if that wouldn't make more evil than good.

Well, if you _really_ _really_ badly want it, we can make
.git/default-origin/ or something... duh, what a stupid name. :)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH] Fix default pull not to do an unintended Octopus.

[Josef Weidendorfer]

On Tuesday 27 September 2005 14:54, you wrote:
> Yes. I'm actually inclined to keep this setup, simply because it is
>
>   * easy
>   * simple
>   * sufficient in most of the cases

I would almost say: sufficient for all cases.
The .git/remotes stuff is about providing a shortcut for remote
repositories and about defaults for this repository.
I am not really sure this is needed, and this second use of a name
(additionally to head names) can be confusing.

> > Perhaps we should have extended the branches file to allow different
> > remote reps and heads depending on the command (fetch/pull/merge/push).
> > A "URL:" is not needed, as you probably like to have different repos for
> > pull and push. And in contrast to the remotes stuff above, a "Merge:"
> > line makes quite sense here: When on "mybranch", a merge should default
> > to merging the heads specified on the Merge line in branches/mybranch.
>
> No. If you are in the branches/ playground, please keep it strictly
> one-to-one mapping. That's what makes it easy and simple and that's what
> makes it good.

Ah, no. Any line in a branches/ file is a pure attribute for the given
head, and does not change its 1:1 relationship.

E.g. a branches/master file with

	Push: git:/.../git.git#public-master
	Merge: origin

would specify:
- If the current head is master, a cg-merge will merge with
head origin
- If the current head is master, a cg-push will publish the
local master to the given remote URL

The branches/master does nothing say about the origin branch/head.

> > When cloning a remote head, Cogito creates a local "origin" head and
> > corresponding mapping in branches/origin. Afterwards, it automatically
> > generates a new local branch "master", which branches of at the
> > origin. Further "cg-updates" (=git fetch+merge) fetch origin, and merge
> > origin into master.
> > I assume that this currently is hardcoded in scripts?
>
> Yes.
>
> > Shouldn't there be created a branches/master, specifying that a default
> > merge should happen with "origin"? This way, an "cg-update" would look
> > into "branches/master" on the "Merge:" line. It sees that "origin" is
> > bound to a remote head, and thus, does a fetch before merging.
>
> If ever doing that, this should be done at some other place than
> branches/.

Hmm, perhaps. We could go with .git/push-defaults and .git/merge-defaults.
But then, IMHO .git/branches should be renamed to .git/fetch-defaults,
as it holds the remote URL needed for fetching changes.

By creating the needed defaults on a cg-clone, you can get rid of the
above mentioned hardcoded things.

> And I'm sceptical about it anyway. Really, introducing some 
> new configuration mechanism just to tell Cogito what default branch name
> should it pick up when you call fetch/update/merge without a parameter?

It is about storing pull/push remote URLs for a given head.
Ok, in the case "merge", it is about defaults (useful to
get rid of the hardcoding of merging origin into master on a cg-update).

I really think that the "push" URL currently is missing in Cogito.
Pushing the master by using the origin URL works, but I would like to
see this working for arbitrary heads.

By the way, am I correct than cogito currently misses a command to
switch the branch? cg-seek is only for temporal switching. What are
the prefered options? A "cg-seek -f", a "cg-jump" or "cg-switch"?

Josef

Re: [PATCH] Fix default pull not to do an unintended Octopus.

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Tuesday 27 September 2005 14:54, you wrote:
>> Yes. I'm actually inclined to keep this setup, simply because it is
>>
>>   * easy
>>   * simple
>>   * sufficient in most of the cases
>
> I would almost say: sufficient for all cases.
> The .git/remotes stuff is about providing a shortcut for remote
> repositories and about defaults for this repository.
> I am not really sure this is needed, and this second use of a name
> (additionally to head names) can be confusing.

I suspect you've never played with remote repositories with 47
different heads.

Re: GIT 0.99.7d, and end of week status.

[Matthias Urlichs]

Hi, Petr Baudis wrote:

> However, I still think
> that the user should be required to specify the to-be-merged head manually
> if the default choice isn't explicitly written in the remotes file.

I tend to agree -- intentional octopus merges are rare enough.
For most people, anyway. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
It is not a good omen when goldfish commit suicide.

Re: GIT 0.99.7d, and end of week status.

[Junio C Hamano]

Matthias Urlichs <smurf@smurf.noris.de> writes:

> I tend to agree -- intentional octopus merges are rare enough.
> For most people, anyway. ;-)

I agree, *and* I think what I proposed is consistent with that.
Essentially, you cannot create an Octopus without asking from
the command line, period.