* Re: [RFC] undo and redo
From: Carl Baldwin @ 2005-08-25 21:42 UTC (permalink / raw)
To: Kirby C. Bohling
Cc: Carl Baldwin, Junio C Hamano, Daniel Barkalow, Linus Torvalds,
git
In-Reply-To: <20050825210929.GF7461@birddog.com>
On Thu, Aug 25, 2005 at 04:09:29PM -0500, Kirby C. Bohling wrote:
> I guess I can see that. I just see it as much easier to manage
> multiple undo-redo states manually. I mean, I wouldn't make anyone
> use git directly if the difference between the two commands bothers
> them. git seems too low a level. I would think one of the
> procelains would be be a better level. However, having a unified
> interface for all the porcelains seems a reasonable request.
Maybe Porcelain is the right place for it. The question would be "Is it
important that porcelains handle undo/redo in a way that interoperates?"
> >
> > Is there something wrong with having flexibility? It seems most of the
> > criticism of this feature is that there is already a way to accomplish
> > what I want to do. Tools that can't be used flexibly are not tools that
> > I like to use. Heck, I'm on UNIX aren't I?
> >
> > Oops, sorry for the rant. I'm really not in a bad mood... really. I
> > hope it didn't sound like that :-). Oh, and I didn't mean to suggest
> > that git is not flexible in other regards. I think its great! Moving
> > along...
> >
> > > Assuming your patch creation and application tools capture all the
> > > meta-data the SCM has (which I believe git does), it's pretty simple
> > > to simulate what you want manaully. With only a handful of
> > > commands.
> >
> > I can simulate git manually too with just a few more commands. Where's
> > the cutoff?
This analogy *was* a bit extreme.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Merges without bases
From: Darrin Thompson @ 2005-08-25 21:29 UTC (permalink / raw)
To: git
In-Reply-To: <1125004228.4110.20.camel@localhost.localdomain>
That didn't come out clearly. Restating:
On Thu, 2005-08-25 at 16:10 -0500, Darrin Thompson wrote:
> Could git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1
> as an implicit empty tree?
>
Could git-read-tree -m treat an argument of "0" as an implicit empty
tree? It mainly seems useful as the first arg in the three arg -m form.
> Once that is done, git octopus will be able to handle the no merge base
> case.
>
Once that is done, git octopus could _optionally_ handle the "I can't
find a merge base" case by passing 0 as the merge base to git-read-tree.
--
Darrin
^ permalink raw reply
* Re: [RFC] undo and redo
From: Carl Baldwin @ 2005-08-25 21:28 UTC (permalink / raw)
To: Kirby C. Bohling
Cc: Junio C Hamano, Carl Baldwin, Daniel Barkalow, Linus Torvalds,
git
In-Reply-To: <20050825204930.GE7461@birddog.com>
On Thu, Aug 25, 2005 at 03:49:30PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> > "Kirby C. Bohling" <kbohling@birddog.com> writes:
> Just out of curiosity, why isn't the SHA1 of 'A' part of the
> diff or patch format? I mean it can't be that hard to add it as a
> single line of data that git can parse to extract that piece of
> information. Then a patch would enable you to do the 3-way merge
> you describe. If added properly "regular" patch would just ignore
> that line. The patch would then record that it is relative to 'A'.
Not a bad idea. It could be ignored in most cases and used when needed.
Carl
> Assuming git could be taught "git-merge-patch" and then take use
> the patch that's saved during the "undo" step and has the anchor for
> the patch to use as the pivot point (as described above). Life
> should be good. There are probably corner cases I don't understand,
> but it sure looks like if you have the pivot or anchor point for the
> patch embedded in the patch, you have all the needed information to
> pull this off.
>
> I would think this would be generally useful outside of the
> context of "undo/redo" also.
>
> Kirby
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [RFC] undo and redo
From: Kirby C. Bohling @ 2005-08-25 21:09 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Junio C Hamano, Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <20050825203733.GA26539@hpsvcnb.fc.hp.com>
On Thu, Aug 25, 2005 at 02:37:33PM -0600, Carl Baldwin wrote:
> On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
> > On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> > <snip...>
> > > Another example is if I'm working on a commit and suddenly get a
> > > brilliant idea for some easy modification that I want to make and commit
> > > by itself before making this commit. I can do this easily with
> > >
> > > % git undo
> > > % carefully make easy change
> > > % git commit
> > > % git redo
> > >
> > > Having a light-weight alternative like this could make the difference
> > > between realizing the easy, brilliant idea and forgetting about it on
> > > the back burner because it was just too cumbersome to make the context
> > > switch.
> > >
> > > The bottom line is that I don't argue against using the existing
> > > work-flows. I hope to add the flexibility to use various work-flows to
> > > fit the job at hand.
> > >
> > <snip...>
> >
> > [Not much of a git user, but am evaluating it for possible future
> > usage]...
> >
> > Why not just save the changes to a file via a patch. Just like you
> > would if you were sending a patch to someone else. I have the work
> > flow you are talking about when I use CVS. I just create a patch,
> > apply the patch in reverse (or run the command to get you a clean
> > working tree in the SCM). Make my unrelated changes commit it.
> > Then apply the patch, possibly resolve merge conflicts, and proceed
> > with finishing my original work.
>
> I used to do this with CVS too. For you and me, people who are patch
> savy veterans, this is great! However, as easy as it is I knew very few
> other developers who even thought about doing it. In the real world,
> many people see a huge difference between:
>
> git diff-cache > $patchfile
> cat $patchfile | patch -R -p1
> do work
> cat $patchfile | patch -p1
>
> AND
>
> git undo
> do work
> git redo
>
> The first one simply never happens with most developers. Most don't
> really think of doing something outside the tool. The second option
> will likely get used. Plus, I know at least one person here who is very
> good with patches and working outside the tool and still would love to
> have the second approach available.
I guess I can see that. I just see it as much easier to manage
multiple undo-redo states manually. I mean, I wouldn't make anyone
use git directly if the difference between the two commands bothers
them. git seems too low a level. I would think one of the
procelains would be be a better level. However, having a unified
interface for all the porcelains seems a reasonable request.
>
> Is there something wrong with having flexibility? It seems most of the
> criticism of this feature is that there is already a way to accomplish
> what I want to do. Tools that can't be used flexibly are not tools that
> I like to use. Heck, I'm on UNIX aren't I?
>
> Oops, sorry for the rant. I'm really not in a bad mood... really. I
> hope it didn't sound like that :-). Oh, and I didn't mean to suggest
> that git is not flexible in other regards. I think its great! Moving
> along...
>
> > Assuming your patch creation and application tools capture all the
> > meta-data the SCM has (which I believe git does), it's pretty simple
> > to simulate what you want manaully. With only a handful of
> > commands.
>
> I can simulate git manually too with just a few more commands. Where's
> the cutoff?
Yes and no. I meant the order and style of commands was nearly
identical. I meant applying the command line in reverse was the
only additional step. As a workflow, I'd just document it in the
HOWTO's. I'm a minimalist in that sense. Sure, I use more then
echo, redirection and netcat even though in theory I could send you
this e-mail with it. IMHO, the above undo/redo doesn't seem to save
enough effort to me. I wouldn't bother learning undo/redo unless it
was superior to the patch way, it's just one more thing I'd have to
remember.
>
> > I see the appeal of not having manually deal with the files, but
> > assuming you don't feel it's branch worthy, and you don't want to
> > have it be something someone else can access externally, it doesn't
> > seem like a feature I can't get almost as simply with existing git
> > commands.
>
> Not having to manually manage a set of patches may seem small but it
> reduces a barrier that may otherwise be just high enough to hurt
> productivity in certain situations.
I don't mean to discourge it's implementation, I really questioned
it because I figured there had to be some more subtle implications I
didn't understand about undo/redo that patch couldn't capture. It
also seems like multiple levels of undo/redo or undo/redo on
multiple branches could get tricky for the user to track and for git
to be able to display the information to the user sanely.
Thanks,
Kirby
^ permalink raw reply
* Merges without bases
From: Darrin Thompson @ 2005-08-25 21:10 UTC (permalink / raw)
To: git
I have a weird situation I want to support. I want to be able to merge a
foreign-tree repeatedly.
What makes the foreign tree foreign is that it may not yet share any
history with this branch.
What I tried to do was fetch foreign tree material and run octopus.
Octopus understandably barfed when it could not find a merge base for
the foreign tree.
What I think is newsworthy is that I figured out a sick way to get it
done. I created an empty tree object and used it as the merge base for
git-read-tree -m.
Could git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1
as an implicit empty tree?
Once that is done, git octopus will be able to handle the no merge base
case.
--
Darrin
^ permalink raw reply
* Re: [RFC] undo and redo
From: Kirby C. Bohling @ 2005-08-25 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <7vmzn5vkg6.fsf@assigned-by-dhcp.cox.net>
On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> "Kirby C. Bohling" <kbohling@birddog.com> writes:
>
> > I guess my final question is what does undo/redo have over saving
> > stuff away in a patch assuming that the patch captures all of the
> > SCM meta-data (the add/move/remove file type commands). If git
> > doesn't capture all the meta-data in a patch, it would seem better
> > to make it do that and get this as a side-affect.
>
> One thing that Carl's undo saves that is not easily available in
> the patch form is the "what is this patch based on" information.
> If you had it, you could do a three-way merge instead of patch
> application.
> You were at A (time flows from left to right) when somebody
> (maybe your bright idea) interrupted you. You take a snapshot
> of your tree state D as a pair <A, D>, and rewind the tree to
> original commit A's state:
>
> -->A
> \
> D
>
> Then you do the work that interrupted you, maybe making commits
> B and then C:
>
> -->A-->B-->C
> \
> D
>
> At this point, you would want to restart working on whatever you
> were doing, which is the difference between A->D applied on top
> of C.
>
> You could keep that information as a patch between A->D and
> apply it on top of C to get there, which is your approach if I
> am reading you correctly. Carl does a three-way merge between C
> and D using A as the pivot point.
Just out of curiosity, why isn't the SHA1 of 'A' part of the
diff or patch format? I mean it can't be that hard to add it as a
single line of data that git can parse to extract that piece of
information. Then a patch would enable you to do the 3-way merge
you describe. If added properly "regular" patch would just ignore
that line. The patch would then record that it is relative to 'A'.
Assuming git could be taught "git-merge-patch" and then take use
the patch that's saved during the "undo" step and has the anchor for
the patch to use as the pivot point (as described above). Life
should be good. There are probably corner cases I don't understand,
but it sure looks like if you have the pivot or anchor point for the
patch embedded in the patch, you have all the needed information to
pull this off.
I would think this would be generally useful outside of the
context of "undo/redo" also.
Kirby
^ permalink raw reply
* RE: cache status after git pull
From: Luck, Tony @ 2005-08-25 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>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
> $ git fetch linus
This sounds like it does what I want ... so I'd like to confirm
before wiring this into my scripts and fingers.
What I want is to get the latest from kernel.org...linus...master
and update my .refs/heads/linus with the new SHA1.
I'd like to be able to do that without touching what is in my
index, and without changing the state of any checked out files.
If that is what the above does, then you are my hero for today :-)
-Tony
^ permalink raw reply
* Re: [RFC] undo and redo
From: Carl Baldwin @ 2005-08-25 20:37 UTC (permalink / raw)
To: Kirby C. Bohling
Cc: Carl Baldwin, Junio C Hamano, Daniel Barkalow, Linus Torvalds,
git
In-Reply-To: <20050825195918.GD7461@birddog.com>
On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> <snip...>
> > Another example is if I'm working on a commit and suddenly get a
> > brilliant idea for some easy modification that I want to make and commit
> > by itself before making this commit. I can do this easily with
> >
> > % git undo
> > % carefully make easy change
> > % git commit
> > % git redo
> >
> > Having a light-weight alternative like this could make the difference
> > between realizing the easy, brilliant idea and forgetting about it on
> > the back burner because it was just too cumbersome to make the context
> > switch.
> >
> > The bottom line is that I don't argue against using the existing
> > work-flows. I hope to add the flexibility to use various work-flows to
> > fit the job at hand.
> >
> <snip...>
>
> [Not much of a git user, but am evaluating it for possible future
> usage]...
>
> Why not just save the changes to a file via a patch. Just like you
> would if you were sending a patch to someone else. I have the work
> flow you are talking about when I use CVS. I just create a patch,
> apply the patch in reverse (or run the command to get you a clean
> working tree in the SCM). Make my unrelated changes commit it.
> Then apply the patch, possibly resolve merge conflicts, and proceed
> with finishing my original work.
I used to do this with CVS too. For you and me, people who are patch
savy veterans, this is great! However, as easy as it is I knew very few
other developers who even thought about doing it. In the real world,
many people see a huge difference between:
git diff-cache > $patchfile
cat $patchfile | patch -R -p1
do work
cat $patchfile | patch -p1
AND
git undo
do work
git redo
The first one simply never happens with most developers. Most don't
really think of doing something outside the tool. The second option
will likely get used. Plus, I know at least one person here who is very
good with patches and working outside the tool and still would love to
have the second approach available.
Is there something wrong with having flexibility? It seems most of the
criticism of this feature is that there is already a way to accomplish
what I want to do. Tools that can't be used flexibly are not tools that
I like to use. Heck, I'm on UNIX aren't I?
Oops, sorry for the rant. I'm really not in a bad mood... really. I
hope it didn't sound like that :-). Oh, and I didn't mean to suggest
that git is not flexible in other regards. I think its great! Moving
along...
> Assuming your patch creation and application tools capture all the
> meta-data the SCM has (which I believe git does), it's pretty simple
> to simulate what you want manaully. With only a handful of
> commands.
I can simulate git manually too with just a few more commands. Where's
the cutoff?
> I see the appeal of not having manually deal with the files, but
> assuming you don't feel it's branch worthy, and you don't want to
> have it be something someone else can access externally, it doesn't
> seem like a feature I can't get almost as simply with existing git
> commands.
Not having to manually manage a set of patches may seem small but it
reduces a barrier that may otherwise be just high enough to hurt
productivity in certain situations.
> I guess my final question is what does undo/redo have over saving
> stuff away in a patch assuming that the patch captures all of the
> SCM meta-data (the add/move/remove file type commands). If git
> doesn't capture all the meta-data in a patch, it would seem better
> to make it do that and get this as a side-affect.
>
> Thanks,
> Kirby
Thanks for your comments.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: cache status after git pull
From: Junio C Hamano @ 2005-08-25 20:26 UTC (permalink / raw)
To: tony.luck; +Cc: git
In-Reply-To: <200508251608.j7PG8XGq016882@agluck-lia64.sc.intel.com>
tony.luck@intel.com writes:
> Aha ... is this the problem that caught me out last week (when
> I ended up with 10 extra files attached to one of my commits)?
Plausible.
> 1) Updated my "linus" branch:
>
> $ git checkout linus && git pull linus
I would assume that just after "git checkout linus" before "git
pull linus", running "git diff -r linus" would have said
nothing.
The second command, "git pull linus", would internally run "git
fetch linus". It depends on how your shorthand "linus" is
defined, but if it is set to update (either overwrite or
fast-forward) the "linus" branch head, then your HEAD pointer
would be updated without updating the index and working tree.
This is bad because now you are telling git that your working
tree is based on updated "linus" branch head, and what you
_could_ commit on top of it is the same thing as what old
"linus" branch head commit used to have. That's why "git
status" output shows the minefield.
If I keep copies of foreign brahches in $GIT_DIR/refs/heads/
somewhere, I never checkout those branches in my working tree.
I always stay in my branches to do my work. I may "diff"
against them to see where I am. Of course I would "resolve"
with them when I feel I am ready.
So, assumes that "linus" short-hand is set up to update
$GIT_DIR/refs/heads/linus with the foreign branch head, the
above example would have been:
$ git checkout master && git pull linus
: examine diffs and be convinced what Linus does is always right.
If my "master" branch is not ready to merge from Linus but I
want to get a feel of what is coming, I would instead do:
: while staying on my master branch
$ git fetch linus
$ gitk linus master ;# or git show-branch linus master
and later when my branch is ready, I would merge it into my
master:
: still staying on my master branch
$ git pull . linus
If you did the pull into your master but it turns out that the
merge result is too messy, you could always reset (back to the
first example):
$ git checkout master && git pull linus
: if merge failed...
$ git reset --hard master
$ git checkout master && git pull linus
: merge succeeds, but I realize that my tree was not quite
: ready to merge from linus -- going back to pre-merge state
$ git reset --hard master^1
The rules for updating $GIT_DIR/refs/ when fetch happens have
been extended and clarified in 0.99.5 quite a bit.
To set up "linus" short-hand to be updated with "master" branch
head from Linus, you would do one of the following:
* Using old style shorthand
$ echo >$GIT_DIR/branches/linus \
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
$ git fetch linus
* 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
$ git fetch linus
* From the command line, having either branches/linus or
remotes/linus from the above two examples:
$ git fetch linus master:linus
To set up "linus" short-hand _not_ to update any local branch
head (i.e. you only use "pull" to update your local branch,
which can be named "linus" branch), you would do one of the
following:
* Using old style shorthand
There is no way to do this using old style shorthand without
an explicit command line <refspec>. See the "From the
command line" example below how to do this.
* 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:
$ git fetch linus
* From the command line, having either branches/linus or
remotes/linus from the above two examples:
$ git fetch linus master:
^ permalink raw reply
* Re: [RFC] undo and redo
From: Junio C Hamano @ 2005-08-25 20:19 UTC (permalink / raw)
To: Kirby C. Bohling; +Cc: Carl Baldwin, Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <20050825195918.GD7461@birddog.com>
"Kirby C. Bohling" <kbohling@birddog.com> writes:
> I guess my final question is what does undo/redo have over saving
> stuff away in a patch assuming that the patch captures all of the
> SCM meta-data (the add/move/remove file type commands). If git
> doesn't capture all the meta-data in a patch, it would seem better
> to make it do that and get this as a side-affect.
One thing that Carl's undo saves that is not easily available in
the patch form is the "what is this patch based on" information.
If you had it, you could do a three-way merge instead of patch
application.
You were at A (time flows from left to right) when somebody
(maybe your bright idea) interrupted you. You take a snapshot
of your tree state D as a pair <A, D>, and rewind the tree to
original commit A's state:
-->A
\
D
Then you do the work that interrupted you, maybe making commits
B and then C:
-->A-->B-->C
\
D
At this point, you would want to restart working on whatever you
were doing, which is the difference between A->D applied on top
of C.
You could keep that information as a patch between A->D and
apply it on top of C to get there, which is your approach if I
am reading you correctly. Carl does a three-way merge between C
and D using A as the pivot point.
^ permalink raw reply
* Re: [RFC] undo and redo
From: Kirby C. Bohling @ 2005-08-25 19:59 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Junio C Hamano, Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <20050825163201.GA3944@hpsvcnb.fc.hp.com>
On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
<snip...>
> Another example is if I'm working on a commit and suddenly get a
> brilliant idea for some easy modification that I want to make and commit
> by itself before making this commit. I can do this easily with
>
> % git undo
> % carefully make easy change
> % git commit
> % git redo
>
> Having a light-weight alternative like this could make the difference
> between realizing the easy, brilliant idea and forgetting about it on
> the back burner because it was just too cumbersome to make the context
> switch.
>
> The bottom line is that I don't argue against using the existing
> work-flows. I hope to add the flexibility to use various work-flows to
> fit the job at hand.
>
<snip...>
[Not much of a git user, but am evaluating it for possible future
usage]...
Why not just save the changes to a file via a patch. Just like you
would if you were sending a patch to someone else. I have the work
flow you are talking about when I use CVS. I just create a patch,
apply the patch in reverse (or run the command to get you a clean
working tree in the SCM). Make my unrelated changes commit it.
Then apply the patch, possibly resolve merge conflicts, and proceed
with finishing my original work.
Assuming your patch creation and application tools capture all the
meta-data the SCM has (which I believe git does), it's pretty simple
to simulate what you want manaully. With only a handful of
commands.
I see the appeal of not having manually deal with the files, but
assuming you don't feel it's branch worthy, and you don't want to
have it be something someone else can access externally, it doesn't
seem like a feature I can't get almost as simply with existing git
commands.
I guess my final question is what does undo/redo have over saving
stuff away in a patch assuming that the patch captures all of the
SCM meta-data (the add/move/remove file type commands). If git
doesn't capture all the meta-data in a patch, it would seem better
to make it do that and get this as a side-affect.
Thanks,
Kirby
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Daniel Barkalow @ 2005-08-25 19:41 UTC (permalink / raw)
To: Jan Veldeman; +Cc: Catalin Marinas, git
In-Reply-To: <20050825070955.GA762@eros.intern.mind.be>
On Thu, 25 Aug 2005, Jan Veldeman wrote:
> Daniel Barkalow wrote:
>
> > I'm not sure how applicable to this situation stgit really is; I see stgit
> > as optimized for the case of a patch set which is basically done, where
> > you want to keep it applicable to the mainline as the mainline advances.
>
> Maybe I forgot to mention this: I would also like to have my development
> tree split up in a patch stack. The separate patches makes tracking the
> mainline a lot easier (conflicts are a lot easier to solve)
I just try to keep things in this state sufficiently briefly that it
doesn't become a problem. I also split things up into a bunch of branches,
rather than into a stack of patches, and only work on parallel development
before I've actually got a candidate for a series.
> But this would assume that once the patch goes into stgit, it won't
> change except when the parent gets updated. I think we will still change
> the patches quite a bit and simultanious by a couple of people.
The extension I had proposed to stgit should work for this; it would let
you version control each patch just like other git projects. I just think
it wouldn't work so well before the group has agreed on what patches there
are.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.5
From: Darrin Thompson @ 2005-08-25 19:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7ci4u7q.fsf@assigned-by-dhcp.cox.net>
On Wed, 2005-08-24 at 19:38 -0700, Junio C Hamano wrote:
> * Update tutorial to cover shared repository style a bit more,
> maybe with a toy project that involves two or three
> repositories.
>
Shameless plug: Feel free to use/modify/steal my writeup:
http://willowbend.cx/archives/2005/08/24/git-epiphany/
--
Darrin
^ permalink raw reply
* [PATCH] cogito -- add -c $commit support
From: James Ketrenos @ 2005-08-25 18:19 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]
Add -c parameter to cg-commit to set commit data based on prior commit.
This will then commit any changes using the author and message from the commit
specified. The actual logic for parsing the old commit values was taken from
git-commit-script.
git-commit-script supports this option via -C, which was already used in cg-commit
for something else.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
---
cg-commit | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
b07037397659763271e946fc15c0b3c61a8fcdfa
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -3,6 +3,8 @@
# Commit into a GIT repository.
# Copyright (c) Petr Baudis, 2005
# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# -c commit based on code in git-commit-script by Linus Torvalds
#
# Commits changes to a GIT repository. Accepts the commit message from
# `stdin`. If the commit message is not modified the commit will be
@@ -45,6 +47,12 @@
# might not actually _have_ any object database. This option is
# normally not interesting.
#
+# -c::
+# Specifify the commit SHA to inherit the GIT_AUTHOR_* variables and
+# commit message from. The GIT_COMMITTER_* variables will not be
+# inherited from the specified commit. This option is typically used
+# when replaying commits from one lineage or repository to another.
+#
# FILES
# -----
# $GIT_DIR/author::
@@ -112,6 +120,7 @@ ignorecache=
infoonly=
commitalways=
missingok=
+use_commit=
msgs=()
while optparse; do
if optparse -C; then
@@ -128,6 +137,8 @@ while optparse; do
force=1
elif optparse -m=; then
msgs[${#msgs[@]}]="$OPTARG"
+ elif optparse -c=; then
+ use_commit="$OPTARG"
else
optfail
fi
@@ -196,6 +207,39 @@ for msg in "${msgs[@]}"; do
echo "$msg" | fmt -s >>$LOGMSG
written=1
done
+
+if [ "$use_commit" ]; then
+ pick_author_script='
+ /^author /{
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ set_author_env=`git-cat-file commit "$use_commit" |
+ sed -ne "$pick_author_script"`
+ eval "$set_author_env"
+ export GIT_AUTHOR_NAME
+ export GIT_AUTHOR_EMAIL
+ export GIT_AUTHOR_DATE
+ git-cat-file commit "$use_commit" |
+ sed -e '1,/^$/d'
+ written=1
+fi >> $LOGMSG
+
# Always have at least one blank line, to ease the editing for
# the poor people whose text editor has no 'O' command.
[ "$written" ] || echo >>$LOGMSG
@@ -239,7 +283,7 @@ echo "CG: vim: textwidth=75" >>$LOGMSG
cp $LOGMSG $LOGMSG2
if tty -s; then
- if ! [ "$msgs" ] || [ "$forceeditor" ]; then
+ if ! ([ "$use_commit" ] || [ "$msgs" ]) || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
if ! [ "$commitalways" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
echo "Log message unchanged or not specified" >&2
[-- Attachment #2: 0001-Add-c-parameter-to-cg-commit-to-set-commit-data-based-on-prior-commit.txt --]
[-- Type: text/plain, Size: 3092 bytes --]
[PATCH] Add -c parameter to cg-commit to set commit data based on prior commit.
This will then commit any changes using the author and message from the commit
specified. The actual logic for parsing the old commit values was taken from
git-commit-script.
git-commit-script supports this option via -C, which was already used in cg-commit
for something else.
Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
---
cg-commit | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
b07037397659763271e946fc15c0b3c61a8fcdfa
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -3,6 +3,8 @@
# Commit into a GIT repository.
# Copyright (c) Petr Baudis, 2005
# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# -c commit based on code in git-commit-script by Linus Torvalds
#
# Commits changes to a GIT repository. Accepts the commit message from
# `stdin`. If the commit message is not modified the commit will be
@@ -45,6 +47,12 @@
# might not actually _have_ any object database. This option is
# normally not interesting.
#
+# -c::
+# Specifify the commit SHA to inherit the GIT_AUTHOR_* variables and
+# commit message from. The GIT_COMMITTER_* variables will not be
+# inherited from the specified commit. This option is typically used
+# when replaying commits from one lineage or repository to another.
+#
# FILES
# -----
# $GIT_DIR/author::
@@ -112,6 +120,7 @@ ignorecache=
infoonly=
commitalways=
missingok=
+use_commit=
msgs=()
while optparse; do
if optparse -C; then
@@ -128,6 +137,8 @@ while optparse; do
force=1
elif optparse -m=; then
msgs[${#msgs[@]}]="$OPTARG"
+ elif optparse -c=; then
+ use_commit="$OPTARG"
else
optfail
fi
@@ -196,6 +207,39 @@ for msg in "${msgs[@]}"; do
echo "$msg" | fmt -s >>$LOGMSG
written=1
done
+
+if [ "$use_commit" ]; then
+ pick_author_script='
+ /^author /{
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ set_author_env=`git-cat-file commit "$use_commit" |
+ sed -ne "$pick_author_script"`
+ eval "$set_author_env"
+ export GIT_AUTHOR_NAME
+ export GIT_AUTHOR_EMAIL
+ export GIT_AUTHOR_DATE
+ git-cat-file commit "$use_commit" |
+ sed -e '1,/^$/d'
+ written=1
+fi >> $LOGMSG
+
# Always have at least one blank line, to ease the editing for
# the poor people whose text editor has no 'O' command.
[ "$written" ] || echo >>$LOGMSG
@@ -239,7 +283,7 @@ echo "CG: vim: textwidth=75" >>$LOGMSG
cp $LOGMSG $LOGMSG2
if tty -s; then
- if ! [ "$msgs" ] || [ "$forceeditor" ]; then
+ if ! ([ "$use_commit" ] || [ "$msgs" ]) || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
if ! [ "$commitalways" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
echo "Log message unchanged or not specified" >&2
^ permalink raw reply
* Re: Storing state in $GIT_DIR
From: Linus Torvalds @ 2005-08-25 18:16 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT, Junio C Hamano
In-Reply-To: <46a038f905082420323b025e3b@mail.gmail.com>
[ Junio, the fact that you can't script the initial commit with "git
commit" is _really_ irritating. ]
On Thu, 25 Aug 2005, Martin Langhoff wrote:
>
> Is there a convention of where/how it is safe to store additional
> (non-git) data in $GIT_DIR?
There's no convention, but I have a suggestion.
> The arch import needs to keep a cache with arch-commit-id =
> git-commit-id mappings, and some notes about what patch-trading Arch
> recorded. It'd be great to be able to store those in
> $GIT_DIR/archimport/ . Is that supported?
Git won't care, so it will work, but things like clone/pull etc also won't
actually ever look there, so it will only work for that one repo.
Now, I have what I consider a clever idea (I've mentioned variations on it
before), but it's entirely possible that people hate it.
The thing is, I think you _do_ want to revision-control the git-commit-id
mappings, but at the same time, you do _not_ want to mess up the resulting
git commit history with arch information.
The reason you want to revision-control them is that that way you get them
on clones, and you can use push/pull to update them. And the reason you
don't want to mess up the commit history is that it's just wrong and ugly.
The git solution to this (which nobody has ever _used_, but which
technically is wonderful) is to have a "side branch" that does not share
any commits (or files, for that matter) in common with the "real branch",
and which is used to track any metadata. In fact, you can obviously have
any number of side branches.
So that "metadata branch" is a real git branch in its own right, but it
doesn't share the same root as the "normal" branch, and it's really
totally independent: you can pull just the main branch (ie somebody who
isn't arch-aware and has no reason to want the arch mappings), or you
could pull just the metadata branch (for example, somebody who doesn't
want to use git, but is trying to match up a git commit ID to whatever
ID's arch uses).
The way to maintain a metadata branch is to have not only a different
branch name (obviously), but also use a totally different index file, so
that you can index both branches in parallell, and you don't actually need
to check out one or the other.
Now, your arch import tools would then use the raw git commands explicitly
to maintain the metadata branch. Every time you do an incremental import
from an arch project, your import scripts would save away the mapping
information into the metadata branch.
I'll make a _really_ stupid example for you, just to make this a bit more
concrete:
mkdir silly-example
cd silly-example
#
# The normal "main branch": use regular git
# infrastructure
#
git init-db
echo "Hello" > file
git update-cache --add file
git commit -m "Main branch"
#
# The metadata branch: magic, very special stuff
#
echo "initial commit:" $(git-rev-parse HEAD) > .archdata
GIT_INDEX_FILE=.git/archindex git-update-cache --add .archdata
arch_index_tree=$(GIT_INDEX_FILE=.git/archindex git-write-tree)
echo "arch index" | git-commit-tree $arch_index_tree > .git/refs/heads/arch-index
(Btw, the above example shows that the initial "git commit" won't take a
"-m" flag, which is really irritating for scripts.)
Then do a "gitk --all", see the two different branches, and realize that
the "arch-index" branch can now contain all the tracking information
necessary to go back-and-forth.
Linus
^ permalink raw reply
* Re: [RFC] undo and redo
From: Kalle Valo @ 2005-08-25 17:39 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050825163201.GA3944@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> For this, I may also use branching, as suggested. I meant for undo/redo
> to be a lighter weight alternative to allow for a faster context switch.
I have been missing the undo command since I started to use git, so
I'll share a user's perspective.
I was also considering undo as a really lightweight command, nothing
too fancy. Usually, I want to try implement something wild or stupid,
but almost immediately decide to abandon it. With 'git undo', this
kind of prototyping would be really easy. For me, redo would be just a
backup if (read: when) I undo something important, nothing more. For
anything else I would use branches, as was suggested.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] undo and redo
From: Carl Baldwin @ 2005-08-25 16:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <7v1x4izjtm.fsf@assigned-by-dhcp.cox.net>
On Wed, Aug 24, 2005 at 10:06:45PM -0700, Junio C Hamano wrote:
> > So, I've tried cloning, pulling to|from, pushing to|from and resolving
> > merges in a repository with undo information stored under
> > .git/refs/undo. None of these operations seem to notice the existence
> > of this directory. I think this is good.
>
> What I meant was that, when "undo/bar" is a tree object, things
> may work in a funny way:
>
> $ git pull ../repo-with-undo/.git refs/undo/bar
>
> $ git push ../other-repo/.git undo/bar:refs/heads/foo
> $ cd ../other-repo && git resolve master foo 'Attempt to merge undo'
I was thinking that undo trees should not be pushed and pulled between
repositories. For this I would use a new branch with proper commits as
Linus suggested.
> I think this undo/redo first needs to be thought about how best
> it is used. My guess is that the workflow you have in mind is
> something like this:
>
> $ git checkout master
> $ hack hack hack
> # Hmph, it almost works, and but my boss says work on
> # some other feature that is more urgent
> $ git undo
> Saved current state as 2005-08-24T20:32:22
> $ work work work
> $ git commit -m 'Boring but urgent fix'
> # Ok, now let's back to the thing I wanted to do.
> $ git redo
> # I happen to know it is the last undo, so I did not name
> # it, but I could have said 2005-08-24T20:32:22
> $ hack more
> $ git commit -m 'Finally fix frotz.'
For this, I may also use branching, as suggested. I meant for undo/redo
to be a lighter weight alternative to allow for a faster context switch.
I am reluctant to commit what I have in my working directory unless I
have taken the time to review the changes using diff tools and cleaned
up considerably. This is my way of being a careful developer. Not all
developers share my style but I know many that do. This makes
committing a heavy weight operation for me.
So, referring to your example. If my 'boss' says that I need to switch
to working on 'Boring but urgent fix' for the next *week* or more I will
likely take the time to make the full context switch to a new branch and
work on the fix. I may also choose to just clone my repository and use
a new working directory. If the fix takes just a day or two I may do
the same.
Now, let's say that the 'fix' is something that I can do in an hour or
two and quickly get back to where I was. In this context, making the
full context switch can feel very cumbersome compared to the amount of
work required to make the fix. Now, a simple 'git undo' will ease this
switch.
Another example is if I'm working on a commit and suddenly get a
brilliant idea for some easy modification that I want to make and commit
by itself before making this commit. I can do this easily with
% git undo
% carefully make easy change
% git commit
% git redo
Having a light-weight alternative like this could make the difference
between realizing the easy, brilliant idea and forgetting about it on
the back burner because it was just too cumbersome to make the context
switch.
The bottom line is that I don't argue against using the existing
work-flows. I hope to add the flexibility to use various work-flows to
fit the job at hand.
[ stuff deleted ]
> $ git checkout master
> $ hack hack hack
> # Hmph, it almost works, and but my boss says work on
> # some other feature that is more urgent
> $ git commit -m 'WIP - fix frotz'
> $ git branch anchor-frotz
> $ git reset --hard master^
> $ work work work
> $ git commit -m 'Boring but urgent fix'
> # Ok, now let's go back to the thing I wanted to do.
> $ git pull . anchor-frotz
> $ rm .git/heads/anchor-frotz
> $ git reset --soft master^
> $ hack more
> $ git commit -m 'Finally fix frotz.'
Again, these are effective. I simply want to provide an alternative
light weight way of accomplishing this.
> The above flow would be something somebody not so organized
> (like myself) would do. A perfect person would have done this:
>
> $ git checkout -b frotz master
> $ hack hack hack
> # Hmph, it almost works, and but my boss says work on
> # some other feature that is more urgent
> $ git commit -m 'WIP - fix frotz'
> $ git checkout master
> $ work work work
> $ git commit -m 'Boring but urgent fix'
> # Ok, now let's go back to the thing I wanted to do.
> $ git checkout frotz
> $ git reset --soft HEAD^
> $ hack more
> $ git commit -m 'Finally fix frotz.'
> $ git checkout master
> $ git pull . frotz
> $ rm .git/refs/heads/frotz
>
> The "perfect person" approach has an added benefit that you
> could have made intermediate commits while doing "hacking",
> because your hackery is always done in the "frotz" branch.
>
> Of course, the scenarios your undo/redo is useful for may not be
> limited to this "handling interrupt" use case. If that is the
> only thing it solves, then I do not see much point having them
> as new commands. I think the undo/redo has potential beyond
> that.
What other potential do you see? I sounds like you had a stream of
thought here that didn't make it in the email. I think there are
probably many ways that it can be useful. I'll ask some of my
colleagues here who have liked undo/redo type functionality what they
think.
I think it would be impossible to think of all of the possibilities
ahead of time. But, if you've thought of some, please share :-)
> So let's first clarify what kind of workflow these new commands
> would help, how well that workflow is applicable in general, and
> then how well these new commands would help that workflow.
>
> > I would be glad to write up documentation and provide a patch.
>
> Sure. I think a set of patches for new commands, and new
> options to existing commands should ideally include the
> following:
>
> - Justification, such as:
>
> - The problems new commands/options address.
> - The expected workflow the new commands/options fit in.
> - How useful that workflow is.
> - How impossible or cumbersome to achieve that workflow using
> existing tools.
>
> Some of these should go to the commit log message, and the
> documentation to describe the "best practice" workflow using
> the new feature should go to Documentation/howto/ directory.
>
> - Documentation. Files Documentation/git-*.txt to describe
> new commands or updates to existing pages, new entry in
> Documentation/Makefile as necessary, and a new link from
> Documentation/git.txt to reach that page.
>
> - Implementation.
>
> - Test scripts in t/ directory, either a new test script or
> updates to existing ones, if the patch is to fix existing
> implementation.
This all sounds reasonable. I'm willing to do this work.
Cheers,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* cache status after git pull
From: tony.luck @ 2005-08-25 16:08 UTC (permalink / raw)
To: git
>* When the branch head pointed by $GIT_DIR/HEAD changes while
> the index file and working tree are looking the other way
> (e.g. somebody pushed into your repository, or you ran "git
> fetch" to update the ref your working tree is on), "git
> checkout" without -f gets confused. Figure out a good way to
> handle this.
Aha ... is this the problem that caught me out last week (when
I ended up with 10 extra files attached to one of my commits)? At
the time the blame was placed on a failed merge not being backed
out correctly. But I only had the failed merge because "get checkout"
had failed to switch branches (and not provided an exit code to
stop my script from trying the merge).
Here's what I did this morning.
1) Updated my "linus" branch:
$ git checkout linus && git pull linus
This appeared to work just fine ... except that when I
check the status of my tree I see:
$ git status
#
# Updated but not checked in:
# (will commit)
#
# modified: arch/ia64/pci/pci.c
# modified: arch/ppc64/kernel/setup.c
# modified: arch/sparc64/kernel/pci.c
# modified: arch/x86_64/defconfig
# modified: drivers/block/cfq-iosched.c
# modified: include/asm-m68k/page.h
# modified: kernel/cpuset.c
#
#
# On branch refs/heads/linus
Which looks like a set of landmines just waiting for me to
step on them!
Today these didn't bite me. "git checkout release" worked
and switched to my release branch (and git status went back
to saying "nothing to commit"). But in the past I think
this is the situation that has caused "git checkout" to fail
with the "fatal: Entry 'blah' would be overwritten by merge. Cannot merge."
-Tony
^ permalink raw reply
* Subject: [PATCH] More missing terms in glossary.txt
From: Johannes Schindelin @ 2005-08-25 14:24 UTC (permalink / raw)
To: Junio C Hamano, git
Describe a DAG and octopus, and change wording of tree object.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/glossary.txt | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
e077919262930f6ce494c963d23317eb2aaf0dd3
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -27,14 +27,20 @@ blob object::
tree object::
An object containing a list of file names and modes along with refs
- to the associated blob and/or tree objects. A tree object is
- equivalent to a directory.
+ to the associated blob and/or tree objects. A tree is equivalent
+ to a directory.
tree::
Either a working tree, or a tree object together with the
dependent blob and tree objects (i.e. a stored representation
of a working tree).
+DAG::
+ Directed acyclic graph. The commit objects form a directed acyclic
+ graph, because they have parents (directed), and the graph of commit
+ objects is acyclic (there is no chain which begins and ends with the
+ same object).
+
index::
A collection of files with stat information, whose contents are
stored as objects. The cache is a stored version of your working
@@ -142,6 +148,10 @@ merge::
merge uses heuristics to accomplish that. Evidently, an automatic
merge can fail.
+octopus::
+ To merge more than two branches. Also denotes an intelligent
+ predator.
+
resolve::
The action of fixing up manually what a failed automatic merge
left behind.
^ permalink raw reply
* Re: [PATCH] Gitk tree view (correction)
From: Linda Walter @ 2005-08-25 13:56 UTC (permalink / raw)
To: git
Hey, that's a nice one. Now I can easily go through my code without using the web interface. It would be nice if you could mark the lines that have changed in bold or whatever. It would also be nice, to add the current uncommitted working version as "newest revision".
Stagger (Please CC me, as I'm not on the list)
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Jan Veldeman @ 2005-08-25 7:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.63.0508231731370.23242@iabervon.org>
Daniel Barkalow wrote:
[...]
> > The parents which should be visible to the outside, will always be versions
> > of my development tree, which I have previously pushed out. My way of
> > working would become:
> > * make changes, all over the place, using stgit
> > * still make changes (none of these gets tracked, intermittent versions are
> > lost)
> > * having a good day: changes looks good, I want to push this out:
> > * push my tree out
> > * stgit-free (which makes the pushed out commits, the new parents of my
> > stgit patches)
> > * restart from top
>
> I'm not sure how applicable to this situation stgit really is; I see stgit
> as optimized for the case of a patch set which is basically done, where
> you want to keep it applicable to the mainline as the mainline advances.
Maybe I forgot to mention this: I would also like to have my development
tree split up in a patch stack. The separate patches makes tracking the
mainline a lot easier (conflicts are a lot easier to solve)
>
> For your application, I'd just have a git branch full of various stuff,
> and then generate clean commits by branching mainline, diffing development
> against it, cutting the diff down to just what I want to push, and
> applying that. Then the clean patch goes into stgit.
But this would assume that once the patch goes into stgit, it won't
change except when the parent gets updated. I think we will still change
the patches quite a bit and simultanious by a couple of people.
>
> > [...]
> > my proposal does something like this, but a little more: not only does it
> > keep track of the link between old-top and new-top, it also keeps track of
> > the links between old-patch-in-between and new-patch-in-between.
> > (This makes sense when the top is being removed or reordered)
>
> I was thinking of this as being the top and bottom commits for a single
> tracked patch, not as a whole series. I think patches lower wouldn't be
> affected, and patches higher would see this as a rebase.
>
ah, ok, I misunderstood that part
Best regards,
Jan
PS. sorry if my responses are sometimes a bit late, I'm trying to find
more time to spend on this list ;-)
^ permalink raw reply
* Re: [RFC] Looking at multiple ancestors in merge
From: Matthias Urlichs @ 2005-08-25 6:56 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508250108100.23242@iabervon.org>
Hi, Daniel Barkalow wrote:
> My proposal is actually to detect when a merge is ambiguous. In order to
> determine that, however, you have to evaluate multiple potential outcomes
> and see if they are actually different. I'm working on an efficient way to
> do that.
Good.
There's also a related problem which I've hit last month or so, where one
view has the same file (or at least one with the same name) added to both
sides of the branch, but the other view doesn't.
Unfortunately, that can happen to both branches independently, so you
really need to choose a merge base per file instead of globally. I suspect
that many of the problem cases simply go away when you do that.
--
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
- -
Jones' Second Law:
The man who smiles when things go wrong has thought of someone
to blame it on.
^ permalink raw reply
* Re: baffled again
From: Tony Luck @ 2005-08-25 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, tony.luck, git
In-Reply-To: <7vzmr63deq.fsf@assigned-by-dhcp.cox.net>
> * Even if it does always choose the nicer choice of the two,
> Tony was lucky (no pun intended). Rather, we were lucky that
> Tony was observant. A careless merger may well have easily
> missed this mismerge (from the human point of view).
Actually I can't take credit here. This was a case of the "many-eyes" of
open source working at its finest ... someone e-mailed me and told me
that I should have backed out the old patch before applying the new one.
While typing the e-mail to say that I already had in the release branch,
I found the problem that it had been "lost" in the merge into the test branch.
But this is a good reminder that merging is not a precise science, and
there is more than one plausible merge in many situations ... and while
GIT will pick the one that you want far more often than not, there is
the possibility that it will surprise you. Maybe there should be a note
to this effect in the tutorial. Git is not magic, nor is it imbued with
DWIM technology.
-Tony
^ permalink raw reply
* Re: [RFC] Looking at multiple ancestors in merge
From: Daniel Barkalow @ 2005-08-25 5:20 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <430D4B75.6060102@gmail.com>
On Wed, 24 Aug 2005, A Large Angry SCM wrote:
> Daniel Barkalow wrote:
> > I'm starting to work on letting the merging process see multiple
> > ancestors, and I think it's messy enough that I should actually discuss
> > it.
> >
> > Review of the issue:
> >
> > It is possible to lost reverts in cases when merging two commits with
> > multiple ancestors, in the following pattern: (letters representing blobs
> > at some filename, children to the right)
> >
> > a-b-b-a-?
> > \ X /
> > a-b-b
> >
> [Lots of stuff deleted]
>
> There seems to be a lot of effort being put into auto-magically choosing
> the "right" merge in the presence of multiple possible merge bases.
> Unfortunately, most (all?) of the proposals are attempting to divine
> intent, and so, are guaranteed to be 100% wrong at least some of the time.
>
> Wouldn't it be better, instead, to detect that current merge being
> attempted is ambiguous and require the user to specify the correct merge
> base? The alternative is a tool that appears to work all of the time but
> does the wrong thing some of the time.
My proposal is actually to detect when a merge is ambiguous. In order to
determine that, however, you have to evaluate multiple potential outcomes
and see if they are actually different. I'm working on an efficient way to
do that.
Then further work could look into eliminating possibilities when
information about the history excludes them. There were two issues in the
case that Tony hit: it ignored a potential correct outcome for the merge,
and it didn't ignore an outcome which could be demonstrated to be
incorrect. The priority is to resolve the first, but things which improve
the second or help with solutions to the second are worth understanding.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] undo and redo
From: Junio C Hamano @ 2005-08-25 5:06 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <20050825024134.GA31886@hpsvcnb.fc.hp.com>
> So, I've tried cloning, pulling to|from, pushing to|from and resolving
> merges in a repository with undo information stored under
> .git/refs/undo. None of these operations seem to notice the existence
> of this directory. I think this is good.
What I meant was that, when "undo/bar" is a tree object, things
may work in a funny way:
$ git pull ../repo-with-undo/.git refs/undo/bar
$ git push ../other-repo/.git undo/bar:refs/heads/foo
$ cd ../other-repo && git resolve master foo 'Attempt to merge undo'
I think this undo/redo first needs to be thought about how best
it is used. My guess is that the workflow you have in mind is
something like this:
$ git checkout master
$ hack hack hack
# Hmph, it almost works, and but my boss says work on
# some other feature that is more urgent
$ git undo
Saved current state as 2005-08-24T20:32:22
$ work work work
$ git commit -m 'Boring but urgent fix'
# Ok, now let's back to the thing I wanted to do.
$ git redo
# I happen to know it is the last undo, so I did not name
# it, but I could have said 2005-08-24T20:32:22
$ hack more
$ git commit -m 'Finally fix frotz.'
I see some problems in this.
One is minor. As you mentioned about "giving undo a symbolic
name", after you accumulate a handful undo, you would need them
to have descriptive names, and a way to list them before using
"git redo".
But as Linus suggested in another reply, you could as well have
done this without inventing these two commands.
$ git checkout master
$ hack hack hack
# Hmph, it almost works, and but my boss says work on
# some other feature that is more urgent
$ git commit -m 'WIP - fix frotz'
$ git branch anchor-frotz
$ git reset --hard master^
$ work work work
$ git commit -m 'Boring but urgent fix'
# Ok, now let's go back to the thing I wanted to do.
$ git pull . anchor-frotz
$ rm .git/heads/anchor-frotz
$ git reset --soft master^
$ hack more
$ git commit -m 'Finally fix frotz.'
The above flow would be something somebody not so organized
(like myself) would do. A perfect person would have done this:
$ git checkout -b frotz master
$ hack hack hack
# Hmph, it almost works, and but my boss says work on
# some other feature that is more urgent
$ git commit -m 'WIP - fix frotz'
$ git checkout master
$ work work work
$ git commit -m 'Boring but urgent fix'
# Ok, now let's go back to the thing I wanted to do.
$ git checkout frotz
$ git reset --soft HEAD^
$ hack more
$ git commit -m 'Finally fix frotz.'
$ git checkout master
$ git pull . frotz
$ rm .git/refs/heads/frotz
The "perfect person" approach has an added benefit that you
could have made intermediate commits while doing "hacking",
because your hackery is always done in the "frotz" branch.
Of course, the scenarios your undo/redo is useful for may not be
limited to this "handling interrupt" use case. If that is the
only thing it solves, then I do not see much point having them
as new commands. I think the undo/redo has potential beyond
that.
So let's first clarify what kind of workflow these new commands
would help, how well that workflow is applicable in general, and
then how well these new commands would help that workflow.
> I would be glad to write up documentation and provide a patch.
Sure. I think a set of patches for new commands, and new
options to existing commands should ideally include the
following:
- Justification, such as:
- The problems new commands/options address.
- The expected workflow the new commands/options fit in.
- How useful that workflow is.
- How impossible or cumbersome to achieve that workflow using
existing tools.
Some of these should go to the commit log message, and the
documentation to describe the "best practice" workflow using
the new feature should go to Documentation/howto/ directory.
- Documentation. Files Documentation/git-*.txt to describe
new commands or updates to existing pages, new entry in
Documentation/Makefile as necessary, and a new link from
Documentation/git.txt to reach that page.
- Implementation.
- Test scripts in t/ directory, either a new test script or
updates to existing ones, if the patch is to fix existing
implementation.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox