Looking at the shortlog information for 2.6.13 there are a lot (eleven)
of changes attributed to me that look like:
Auto merge with /home/aegl/GIT/linus
This is valid (I really did make all those commits, they happen every
time I merge the "linus" branch into my release branch, which I like to
>I am tempted to move this logic to "git fetch" instead, because
>it has the same issue. Tony's "linus" branch example has been
>updated to do a "git fetch" instead of "git pull" from the
>earlier description in his howto, but if he happens to be on the
>"linus" branch, he would still have this sa
>To set up "linus" short-hand to be updated with "master" branch
>head from Linus, you would do one of the following:
>
> * Using new style shorthand
>
>$ cat >$GIT_DIR/remotes/linus \
>URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>Pull: master:linus
>
>I think git did the "right thing", it just happened to be the thing that
>Tony didn't want. Which makes it the "wrong thing", of course, but from a
>purely technical standpoint, I don't think there's anything really wrong
>with the merge.
On the plus side ... at least it wasn't a dumb user error
>Yup. Think of it as a good exercise in git ;)
Fixed now (I hope).
-Tony
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
>Now, I suspect you didn't mean to commit that thing: it really looks like
>you've mixed up your patches somehow, because the commit message seems to
>match only a very small portion of the patch.
>
>Did you perhaps have a failed merge or something that was in your index
>when you applied that
Yesterday I was all happy ... Linus pulled a couple of changes from
my tree, and after I did a pull back from his tree into my "linus"
tracking branch, my status scripts correctly identified the branches
that I'd been using to track those changes as being no longer needed.
But this morning I ran a
Small fix (use "git branch" to make branches, rather than "git checkout -b").
Optimization for trivial patches (apply to release and merge to test).
Three sample scripts appended.
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
diff --git a/Documentation/howto/using-topic-branches.txt
b/Docu
I've just got around to noticing some of the new (to
me) features in git, and started experimenting with
branches.
I see that when I switch view to a different
branch with:
$ git checkout -f someoldbranch
that any files that exist in my previous branch view
but not in "someoldbranch" are
>But if you download 1000 files of the 1010 you need, and then your network
>goes down, you will need to download those 1000 again when it comes back,
>because you can't save them unless you have the full history.
So you could make the temporary object repository persistant between pulls
to avoi
>I'd prefer not to lose the information. If someone has committed a
>change at 2am, I like to know that it was 2am for _them_. It helps me
>decide where to look first for the cause of problems. :)
I'd think the 8:00am-before-the-first-coffee checkins would be the
most worrying :-)
>It also helps
11 matches
Mail list logo
