From: Steven Grimm <koreth@midwinter.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: GIT vs Other: Need argument
Date: Thu, 19 Apr 2007 11:18:58 -0700 [thread overview]
Message-ID: <4627B292.6080202@midwinter.com> (raw)
In-Reply-To: <7vejmg9a1z.fsf@assigned-by-dhcp.cox.net>
Thanks for that detailed writeup. It squares pretty well with my
understanding.
Junio C Hamano wrote:
> (2).............M?
> / .
> 1-----3a-3b-3c-3d
>
> [...]
> (2')
> .
> 1-----3a-3b-3c-3d
>
>
> The patch series I "vaguely recalled" in my previous message
> handled this special case where the branch being merged
> (i.e. 3d) was a fast-forward of the current commit (i.e. 1).
>
I think this is actually the case I'd be most concerned about getting
right for those people who are coming from svn and want to change their
workflow as little as possible at first. The class of people who would
exclusively use an "svnish-commit" alias that did "git commit;git push"
-- that is, who never do local commits -- would always find themselves
with this setup.
> 3. Always serialize by rebasing. The structure you would want
> to end up with is like this:
>
> 2a'-2b'.(2c')
> /
> 1-----3a-3b-3c-3d
>
You are correct in pointing out later on that my fetch+rebase workflow
fits this structure. And for my particular environment it's actually the
only one I can use a lot of the time, because I'm usually pushing to a
shared git-svn repository (or working in a git-svn repo of my own), from
which the changes will get committed back to svn. Eric Wong has warned
that git-svn doesn't deal well with merges; it expects linear history.
So for now this is the structure I need to end up with, at least until
git-svn learns how to deal with nonlinear ancestry, if that's even
possible at all given svn's inherent limitations.
I look forward to the day when git has built up enough critical mass
here that we can just switch over to it completely and ditch that kind
of restriction. With that happy day in mind, I'd still love to see the
other workflows made as painless as possible, so more comments below.
> For the second workflow, you would:
>
> 2-a. first make a tentative commit 2c
> 2-b. merge what was ready on your end and the other side:
> 2-c. roll forward the local change you have in 2c:
>
> We probably could help automating this, but your "git pull"
> session transcript need to look like this:
>
> $ git pull origin
> First stashing away of your local changes...
> Resolving conflicts between 2b and 3d.
> Conflicted merge. Please resolve and commit.
> $ edit ; test
> $ git commit ;# to record M
> Committed the merge result.
> You have stashed local changes further to roll forward.
> $ git unstash local-changes
> Resolving conflicts between M and 2c.
> Local changes conflicted during roll-forward.
> Leaving resulting mess in the working tree for you to sort out.
>
I wonder if it makes sense to automate that even more and make git pull
behave a bit statefully like rebase does:
$ git pull origin
Stashing local changes.
Resolving conflicts, pass 1.
Conflicts! Please resolve.
$ edit ; test
$ git pull --continue
Committing revision M.
Unstashing your local changes.
Resolving conflicts, pass 2.
Local changes conflicted during roll-forward. Sort it out.
$
When git pull --continue does the commit, it *might* be nice for it to
do a variant of commit -a: if the user has modified all the conflicting
files, *and* not done an update-index on any of them manually, then do
the update-index implicitly. (That "and" part would be to prevent it
from tripping up experienced git users who want to manually mark the
conflicting files as resolved by running update-index.) I'm not sure
that's actually a good idea, though it'd save some commands most of the
time; the danger, of course, is that you could end up committing a
half-resolved file by accident. But then I guess there's nothing
preventing you from doing that with update-index today.
But that's attractive because it's exactly two git commands in the most
complex case (conflicts in the merge of committed revisions) and only
one git command in the simplest cases (no conflicts or conflicts only in
the working copy edits.) In the case of no working copy edits,
--continue would just do the commit for you.
To make pull and rebase even more consistent, one could also allow git
pull --abort to roll back the pull during a conflict resolution, whether
or not it's a working-copy-edits one. People might find that a handy
shortcut in other workflows too; it would probably just do a hard reset
back to the pre-merge revision in the no-working-copy-edits case.
Obviously that wouldn't be new functionality, just an arguably slightly
more intuitive way to do it than what exists now.
> If you want to automate this, you can use this four-liner
> shell script:
>
> #!/bin/sh
> git commit || exit
> git fetch origin || exit
> git rebase origin || exit
> git reset HEAD^
>
Actually I think I like the idea of making that a little more robust and
having it take a --continue option like I described above. No reason it
can't keep track of its current state. I will spend some time this
weekend doing that.
-Steve
next prev parent reply other threads:[~2007-04-19 18:19 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-17 9:02 GIT vs Other: Need argument Pietro Mascagni
2007-04-17 9:13 ` Matthieu Moy
2007-04-17 10:26 ` Andy Parkins
2007-04-17 14:32 ` Alex Riesen
2007-04-17 10:37 ` Martin Langhoff
2007-04-17 15:28 ` Linus Torvalds
2007-04-17 17:07 ` Matthieu Moy
2007-04-17 10:33 ` Martin Langhoff
2007-04-17 14:39 ` Alex Riesen
2007-04-25 8:58 ` Dana How
2007-04-25 10:35 ` Alex Riesen
2007-04-17 10:45 ` Tomash Brechko
2007-04-17 15:41 ` Guilhem Bonnefille
2007-04-17 17:18 ` Andy Parkins
2007-04-17 17:30 ` Shawn O. Pearce
2007-04-17 19:36 ` Marcin Kasperski
2007-04-18 10:05 ` Johannes Schindelin
2007-04-18 16:07 ` Linus Torvalds
2007-04-18 16:31 ` Nicolas Pitre
2007-04-18 16:49 ` Bill Lear
2007-04-18 17:43 ` Matthieu Moy
2007-04-18 17:50 ` Nicolas Pitre
2007-04-19 13:16 ` Matthieu Moy
2007-04-19 18:44 ` Petr Baudis
2007-04-20 9:04 ` Matthieu Moy
2007-04-18 20:57 ` Theodore Tso
2007-04-18 20:08 ` Guilhem Bonnefille
2007-04-18 20:19 ` Linus Torvalds
2007-04-18 21:45 ` Daniel Barkalow
2007-04-18 21:21 ` Michael K. Edwards
2007-04-19 8:37 ` Johannes Schindelin
2007-04-19 13:29 ` Matthieu Moy
2007-04-19 9:24 ` Johannes Schindelin
2007-04-19 12:21 ` Alex Riesen
2007-04-19 12:22 ` Christian MICHON
2007-04-19 12:37 ` Johannes Schindelin
2007-04-19 12:54 ` Christian MICHON
2007-04-19 16:43 ` Linus Torvalds
2007-04-19 17:49 ` Marcin Kasperski
2007-04-19 20:57 ` Linus Torvalds
2007-04-23 18:54 ` Carl Worth
2007-04-23 19:52 ` Josef Weidendorfer
2007-04-23 22:12 ` Carl Worth
2007-04-23 22:23 ` Junio C Hamano
2007-04-23 22:58 ` Carl Worth
2007-04-23 23:24 ` Linus Torvalds
2007-04-23 23:55 ` Brian Gernhardt
2007-04-24 1:31 ` Daniel Barkalow
2007-04-24 5:15 ` Junio C Hamano
2007-04-24 14:23 ` J. Bruce Fields
2007-04-24 15:01 ` Linus Torvalds
2007-04-30 4:31 ` J. Bruce Fields
2007-04-25 13:12 ` Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument) Carl Worth
2007-04-25 14:09 ` Carl Worth
2007-04-25 14:55 ` Linus Torvalds
2007-04-25 16:28 ` Carl Worth
2007-04-25 18:07 ` Nicolas Pitre
2007-04-25 19:03 ` Carl Worth
2007-04-25 19:17 ` Making git disappear when talking about my code Junio C Hamano
2007-04-25 19:22 ` Nicolas Pitre
2007-04-25 20:26 ` Carl Worth
2007-04-25 20:23 ` Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument) Nicolas Pitre
2007-04-25 14:51 ` Linus Torvalds
2007-04-25 19:44 ` Daniel Barkalow
2007-04-25 19:56 ` Making git disappear when talking about my code Junio C Hamano
2007-04-25 20:29 ` Linus Torvalds
2007-04-25 20:32 ` Nicolas Pitre
2007-04-25 21:38 ` Daniel Barkalow
2007-04-25 20:29 ` Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument) Carl Worth
2007-04-25 22:39 ` Daniel Barkalow
2007-04-25 20:31 ` Nicolas Pitre
2007-04-23 23:22 ` GIT vs Other: Need argument Junio C Hamano
2007-04-19 20:49 ` Johannes Schindelin
2007-04-20 15:54 ` History cleanup/rewriting script for git Jan Harkes
2007-04-20 18:39 ` Johannes Schindelin
2007-04-20 18:44 ` Petr Baudis
2007-04-20 20:36 ` Jan Harkes
2007-04-19 12:15 ` GIT vs Other: Need argument Marcin Kasperski
2007-04-19 12:33 ` Johannes Schindelin
2007-04-19 12:42 ` Marcin Kasperski
2007-04-19 13:36 ` Johannes Schindelin
2007-04-19 14:27 ` J. Bruce Fields
2007-04-19 12:45 ` Theodore Tso
2007-04-19 12:46 ` [ANNOUNCE] Cogito is for sale Petr Baudis
2007-04-19 13:32 ` Matthieu Moy
2007-04-19 20:23 ` Junio C Hamano
2007-04-19 20:42 ` Johannes Schindelin
[not found] ` <1176984208.30690.18.camel@cauchy.softax.local>
2007-04-19 12:28 ` GIT vs Other: Need argument Johannes Schindelin
2007-04-19 12:37 ` Marcin Kasperski
2007-04-19 13:32 ` Johannes Schindelin
[not found] ` <200704172239.20124.andyparkins@gmail.com>
2007-04-19 11:59 ` Marcin Kasperski
2007-04-19 12:48 ` Alex Riesen
2007-04-19 12:57 ` Andy Parkins
2007-04-20 6:22 ` Shawn O. Pearce
2007-04-20 13:03 ` Eric Blake
2007-04-18 12:40 ` Guilhem Bonnefille
2007-04-18 13:26 ` Andy Parkins
2007-04-18 17:08 ` Steven Grimm
2007-04-19 0:33 ` Jakub Narebski
2007-04-19 1:24 ` Steven Grimm
2007-04-19 2:08 ` Jakub Narebski
2007-04-19 8:48 ` Johannes Schindelin
2007-04-19 8:57 ` Julian Phillips
2007-04-19 19:03 ` Steven Grimm
2007-04-19 21:00 ` Johannes Schindelin
2007-04-19 2:11 ` Junio C Hamano
2007-04-19 6:02 ` Junio C Hamano
2007-04-19 18:18 ` Steven Grimm [this message]
2007-04-19 23:30 ` Junio C Hamano
2007-04-20 5:32 ` Shawn O. Pearce
2007-04-20 9:04 ` Jakub Narebski
2007-04-20 10:18 ` Karl Hasselström
2007-04-20 10:39 ` Junio C Hamano
2007-04-20 13:57 ` Petr Baudis
2007-04-20 8:36 ` Junio C Hamano
2007-04-20 16:42 ` Steven Grimm
2007-04-18 20:54 ` Yann Dirson
2007-04-18 3:09 ` Sam Vilain
2007-04-18 20:49 ` Yann Dirson
2007-04-25 8:55 ` Dana How
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4627B292.6080202@midwinter.com \
--to=koreth@midwinter.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).