On Thu, Apr 10, 2008 at 01:25:00AM +0300, Teemu Likonen wrote:

quoted text
> Hmm, maybe. I recently wanted to join two purely local repos together.
> Both of them had just one branch. Totally different histories so no
> actual mergin would happen; just two branches in the same repo. I don't
> know why but "git fetch /the/other/repo/" just happened to be the one
> I tried first. I saw it fetched something but as no new branch appeared
> and I had never heard of this FETCH_HEAD thing it was a "didn't work,
> what should I try next?" thing. I think your idea of showing

Ah, OK. In that case, I think the right thing to do would not be to set
up a remote, but to fetch explicitly into a local branch. I assume when
you say "joining" you mean "so I can get rid of the individual ones".
So something like:

  cd repo1
  git fetch ../repo2 master:repo2-topic

which creates refs/heads/repo2 in repo1, and you can safely delete
repo2.

If you _did_ want to keep repo2 around indefinitely, and you are
"joining" so that you can do diffs, then you probably do want a remote
with tracking branches.

  cd repo1
  git remote add repo2 ../repo2
  git fetch repo2
  git diff repo2/master...master

quoted text
> >   From git://host/path/to/repo
> >    * [new branch]      foo -> FETCH_HEAD
> 
> would be really good. At least to me this would have been enough
> information. As I'm starting to see the "point of doing fetch <URL>"
> I take back what I proposed. Just a bit more information would be nice.

I wonder if people like Linus who do a lot of one-off pulls would find
that too cluttery. I guess we can post a patch and see. ;)

quoted text
> I have to agree with Ingo Molnar that sometimes Git is a bit un- or even
> disinformative about what happened. One example is this "git fetch
> <URL>". Maybe it's not a "sane thing to do" but users are like this. We
> just try something and learn from it. To me "git fetch <URL>" was
> a broken command (UI-wise) until I read your message (thanks again!). If
> Git had told me that it created FETCH_HEAD I had learned fetch's habits
> myself and likely wouldn't have come up with this "broken command"
> conclusion.

Sure. In my other message I talked about workflows not to imply "how
dare you explore the commands!" but rather to see where you were coming
from. I agree that a lot of git messages could be improved. So I think
the take-away lesson is not that there needs to be some huge change in
behavior or what input is accepted, but that git-fetch without tracking
branches should probably give a clue that it did _something_.

quoted text
> Another thing I spoke of was this refs/ stuff. I know my way around with
> them now, so maybe they are not actually confusing to me anymore. It's
> just that I have noticed a pattern: I always use refs/heads/... in
> certain places and refs/remotes/ in certain places. If such a pattern is
> very common (well, I don't know if it is) one starts to think that maybe
> the pattern can/should be hidden and made part of the tool. Just
> thoughts.

I almost never use refs/remotes/ or refs/heads/. Some effort has been
put into doing the right thing with partial refnames (which you can of
course override by being more specific). Do you have specific examples
of where you use the full refname? I suspect it is either not required
(and documentation may be out of date), or it is a bug we could fix. :)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html