Re: Bring together merge and rebase

[Carl Baldwin]

On Sat, Jan 06, 2018 at 10:29:19AM -0700, Carl Baldwin wrote:
> To me, this is roughly equivalent to saying that parent pointers
> embedded in a commit object is a good idea because we want a richer
> relationship than mere "parent". Look how much we've done with this
> simple relationship. Similarly, the new relationship that I'm
> proposing handles much more than the simple m==n==1 case. Read below
> for more detail.

Of course, I meant to say "is not a good idea" in the above paragraph.
Please pardon my error.

Re: Bring together merge and rebase

[Carl Baldwin]

On Fri, Jan 05, 2018 at 12:14:28PM -0800, Junio C Hamano wrote:
> Martin Fick  writes:
> 
> > These scenarios seem to come up most for me at Gerrit hack-
> > a-thons where we collaborate a lot in short time spans on 
> > changes.  We (the Gerrit maintainers) too have wanted and 
> > sometimes discussed ways to track the relation of "amended" 
> > commits (which is generally what Gerrit patchsets are).  We 
> > also concluded that some sort of parent commit pointer was 
> > needed, although parent is somewhat the wrong term since 
> > that already means something in git.  Rather, maybe some 
> > "predecessor" type of term would be better, maybe 
> > "antecedent", but "amended-commit" pointer might be best?
> 
> In general, I agree that you would want richer set of "relationship"
> than mere "predecessor" or "related", but I do not think "amended"
> is sufficient.  I certainly do not think a "pointer" embedded in a
> commit object is a good idea, either (a new commit object header is

To me, this is roughly equivalent to saying that parent pointers
embedded in a commit object is a good idea because we want a richer
relationship than mere "parent". Look how much we've done with this
simple relationship. Similarly, the new relationship that I'm proposing
handles much more than the simple m==n==1 case. Read below for more
detail.

> out of question, but I doubt it is a good idea to make a pointer
> back to an existing commit as a part of the log message).
> 
> You may used to have a set of n-patches A1, A2, ..., An, that turned
> into m-patches X1, X2, ..., Xm, after refactoring.  During the work,
> it may turned out that some things the original tried to do are not
> sensible and dropped, while some other things are added in the final.
> series.  
> 
> When n==m==1, "amended" pointer from X1 to A1 may allow you to
> answer "Is this the first attempt?  If this is refined, what did the
> earlier one look like?" when given X1, but you would also want to
> answer a related question "This was a good start, but did the effort
> result in a refined patch, and if so what is it?" when given A1, and
> "amended" pointer won't help at all.  Needless to say, the "pointer"
> approach breaks down when !(n==m==1).

It doesn't break down. It merely presents more sophisticated situations
that may be more work for the tool to help out with. This is where I
think a prototype will help see these situations and develop the tool to
manage them.

When each of n commits is amended or rebased trivially into m==n new
commits then each change is represented by a distinct graph of
predecessors that can be followed independently of others. With rebase,
this is accomplished by using only "pick" in interactive mode or not
using interactive mode at all (and no autosquash).

The more sophisticated cases can be broken down into two operations that
change the number of resulting commits.

  1. Squashing two commits together ("fixup", "squash"). In this case,
 the resulting commit will have two or more pointers. This clearly
 shows that multiple changes converged into one at this point.

  2. Splitting a single commit into multiple new commits ("edit"). In
 this case, the graph shows multiple new commits pointing to the
 same predecessor. In my experience, this is less common. It also is
 a little more challenging to think about the tool managing
 divergent work but I think it is possible.

The end result is m commits where m can be any positive number (even,
coincidentally, n). However, the graph of amended commits still tells
the story quite well. Even if commits are reordered, the graphs can
still be useful. The predecessor graph is independent of the parent
graph which makes up normal git commit history so it isn't inherently
bad that the order of commits was changed.

We can dream up some very interesting graphs. Sure, as we do
increasingly more complicated history rewriting, it is going to be
increasingly more difficult for the tool to help out. I'm not really
deterred by this at this point. I want to experiment and work it out
with a prototype.

My primary objective personally is to detect where work on a single
change has diverged by working on it from more than one workspace
whether its multiple people chipping in or just me. Merely having the
ability to reject an update that clobbers divergent work is a big win.
No more silent corruption of work.

My secondary objective is to develop a tool to help get the divergent
work back on track. I believe that in the majority of common cases, this
tool can be successful in either finding an automatic way to bring the
divergent work back into a new revision of the change or present the
user with conflicts to resolve that end up being much easier than what
I've had to do in past experience with rebase workflows.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Thu, Jan 04, 2018 at 10:09:19PM -0700, Carl Baldwin wrote:
> This would be very cool. I've wanted to tackle this for a long time. I
> think I even filed an issue with gerrit about this years ago.

Yep, it turned out that it was a duplicate but I described what I did to
work around it.

https://bugs.chromium.org/p/gerrit/issues/detail?id=2375

Re: Bring together merge and rebase

[Carl Baldwin]

On Thu, Jan 04, 2018 at 12:19:34PM -0700, Martin Fick wrote:
> On Tuesday, December 26, 2017 12:40:26 AM Jacob Keller 
> wrote:
> > On Mon, Dec 25, 2017 at 10:02 PM, Carl Baldwin 
> <c...@ecbaldwin.net> wrote:
> > >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin 
> <c...@ecbaldwin.net> wrote:
> > >> A bit of a tangent here, but a thought I didn't wanna
> > >> lose: In the general case where a patch was rebased
> > >> and the original parent pointer was changed, it is
> > >> actually quite hard to show a diff of what changed
> > >> between versions.
> > 
> > My biggest gripes are that the gerrit web interface
> > doesn't itself do something like this (and jgit does not
> > appear to be able to generate combined diffs at all!)
> 
> I believe it now does, a presentation was given at the 
> Gerrit User summit in London describing this work.  It would 
> indeed be great if git could do this also!

This would be very cool. I've wanted to tackle this for a long time. I
think I even filed an issue with gerrit about this years ago.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Thu, Jan 04, 2018 at 01:06:27PM -0700, Martin Fick wrote:
> On Tuesday, December 26, 2017 01:31:55 PM Carl Baldwin 
> wrote:
> ...
> > What I propose is that gerrit and github could end up more
> > robust, featureful, and interoperable if they had this
> > feature to build from.
> 
> I agree (assuming we come up with a well defined feature)
> 
> > With gerrit specifically, adopting this feature would make
> > the "change" concept richer than it is now because it
> > could supersede the change-id in the commit message and
> > allow a change to evolve in a distributed non-linear way
> > with protection against clobbering work.
> 
> We (the Gerrit maintainers) would like changes to be able to 
> evolve non-linearly so that we can eventually support 
> distributed Gerrit reviews, and the amended-commit pointer 
> is one way I have thought to resolve this.

I really think that keeping these references is the key to doing this.

> > I have no intention to disparage either tool. I love them
> > both. They've both made my career better in different
> > ways. I know there is no guarantee that github, gerrit,
> > or any other tool will do anything to adopt this. But,
> > I'm hoping they are reading this thread and that they
> > recognize how this feature can make them a little bit
> > better and jump in and help. I know it is a lot to hope
> > for but I think it could be great if it happened.
> 
> We (the Gerrit maintainers) do recognize it, and I am glad 
> that someone is pushing for solutions in this space.  I am 
> not sure what the right solution is, and how to modify 
> workflows to deal better with this.  I do think that starting 
> by making your local repo track pointers to amended-commits, 
> likely with various git hooks and notes (as also proposed by 
> Johannes Schindelin), would be a good start.   With that in 
> place, then you can attack various specific workflows.

I have started a prototype that I will use to demonstrate this. I hope
to have something in a couple of weeks. I do have a day job also, so it
will be slow going. One idea that I had was to put my own server with
special hooks in it in front of gerrit to illustrate how collaboration
on a gerrit change, or even a chain of them, can be made safe. It would
act as a middle man between my client and the gerrit server. I'd just
have to change remote reference on my client to demonstrate.

> If you want to then attack the Gerrit workflow, it would be 
> good if you could prevent pushing new patchests that are 
> amended versions of patchsets that are out of date.  While 
> it would be great if Gerrit could reject such pushes, I 
> wonder if to start, git could detect and it prevent the push 
> in this situation?  Could a git push hook analyze the ref 
> advertisements and figure this out (all the patchsets are in 
> the advertisement)?  Can a git hook look at the ref 
> advertisement?

I'll think about this. At the least, the hook would have to look at the
server to see if there are new revisions. It would be difficult to close
race conditions that occur because the client will always be using
potentially out of date information even if it just went and pulled down
the latest stuff. I think I still like my middle man idea better as a
short term proof of concept.

Preventing pushing amended/rebased versions of out of date changes is
simple. Follow the "predecessor" references until you hit a known
commit. If that commit is the latest revision of the change then it is
up to date. If that commit not the latest revision, then it is out of
date. Reject it. This is what I plan to illustrate in my middle man
server.

If you traverse the entire graph of predecessors without finding a known
commit, then you have a new change. (In fact, the changeset id in the
commit message in a gerrit change seems unnecessary at this point). It
gets a little more complicated when you think about combining/squashing
changes (resulting in two or more "predecessor" references from a single
commit) or dividing a change into multiple but it works.

The harder part is the push/pull interaction between client and server.
When you go to push your amended update to a patchset, you want git to
send along any other new commits to complete the predecessor graph on
the server side. For example, you might rebase your commit and then
amend it to fix something. Personally, I'd like the rebase and the amend
to both be kept separately.

Similarly, when you've just had a push rejected because you're out of
date, you want to be able to easily pull down the commits you're missing
so that you can merge locally and try to push again.

You also don't want gc to garbage collect the intermediate commits. I
think gerrit uses many references internally in the git repo to "pin&q

Re: Bring together merge and rebase

[Carl Baldwin]

On Thu, Jan 04, 2018 at 12:54:00PM -0700, Martin Fick wrote:
> On Monday, December 25, 2017 06:16:40 PM Carl Baldwin wrote:
> > On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o 
> wrote:
> > Look at what happens in a rebase type workflow in any of
> > the following scenarios. All of these came up regularly
> > in my time with Gerrit.
> > 
> > 1. Make a quick edit through the web UI then later
> > work on the change again in your local clone. It is easy
> > to forget to pull down the change made through the UI
> > before starting to work on it again. If that happens, the
> > change made through the UI will almost certainly be
> > clobbered.
> > 
> > 2. You or someone else creates a second change that is
> > dependent on yours and works on it while yours is still
> > evolving. If the second change gets rebased with an older
> > copy of the base change and then posted back up for
> > review, newer work in the base change has just been
> > clobbered.
> > 
> > 3. As a reviewer, you decide the best way to explain
> > how you'd like to see something done differently is to
> > make the quick change yourself and push it up. If the
> > author fails to fetch what you pushed before continuing
> > onto something else, it gets clobbered.
> > 
> > 4. You want to collaborate on a single change with
> > someone else in any way and for whatever reason. As soon
> > as that change starts hitting multiple work spaces, there
> > are synchronization issues that currently take careful
> > manual intervention.
> 
> These scenarios seem to come up most for me at Gerrit hack-
> a-thons where we collaborate a lot in short time spans on 
> changes.  We (the Gerrit maintainers) too have wanted and 
> sometimes discussed ways to track the relation of "amended" 
> commits (which is generally what Gerrit patchsets are).  We 
> also concluded that some sort of parent commit pointer was 
> needed, although parent is somewhat the wrong term since 
> that already means something in git.  Rather, maybe some 
> "predecessor" type of term would be better, maybe 
> "antecedent", but "amended-commit" pointer might be best?

I like "replaces" as I have proposed or "supersedes". "predecessor" also
seems pretty good. I may add that to my list of favorites.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Wed, Dec 27, 2017 at 03:35:58PM +0200, Alexei Lozovsky wrote:
> I think the reasoning behind Theo's words is that it would be better
> to first implement the commit relationship tracking as an add-in which
> uses commit messages for data storage, then evaluate its usefulness
> when it's actually available (including extensions to gitk and stuff
> to support the new metadata), and then it could be moved into core git
> data structures, when it has proven itself useful. It's not a trivial
> feature which warrants immediate addition to git and its design can
> change when faced with real- world use-cases, so it would be bad for
> compatibility to rush its addition. Storage location for metadata
> seems to be an implementation detail which could be technically
> changed more or less easily. But it's much easier to ignore a trailer
> in commit message in the favor of a commit header field than to
> replace a deprecated commit header field with a better one, which
> could cause massive headache for all git repositories in the world.

Yeah, this is a point that everyone is eager to make instead of really
trying to understand what I'm trying to do and offering constructive
suggestions. It's not that I'm not listening. I'm not really concerned
about headers vs trailers or the asthetics of the whole thing as much as
I'm concerned about how the server / client interaction will be. I worry
that anything that I come up with that isn't implemented in the regular
git core push and fetch will end up being awkward or end up needing to
reimplement a lot of what's already in git. But, maybe it just needs a
little more thought. Let me try to think through it...

Imagine John posts a new change up for review to a review server. The
current master points at commit A and so he grabs it and drafts his
first proposal, B1.

digraph history {
B1 -> A
}

Soon after posting, he notices a couple of simple errors and uses the
web UI to correct them. This creates B2. (Dashed edges are replaces
references).

digraph history {
B1 -> A
B2 -> A
B2 -> B1 [ style="dashed"; ]
}

Anna reviews B2 and finds a small nit. She asks John if she can just fix
it and push up a new review. He agrees. She pushes up B3.

digraph history {
B1 -> A
B2 -> A
B3 -> A
B2 -> B1 [ style="dashed"; ]
B3 -> B2 [ style="dashed"; ]
}

John goes back to his workspace and does a little more work on B. He
creates the fourth revision, B4 but since he didn't update his workspace
with the other two most recent revisions, his new revision is derived
from B1.

digraph history {
B1 -> A
B2 -> A
B3 -> A
B4 -> A
B2 -> B1 [ style="dashed"; ]
B3 -> B2 [ style="dashed"; ]
B4 -> B1 [ style="dashed"; ]
}

John then pushes to the server. I imagined that would be a command
similar to what gerrit does.

git push codereview refs/for/master

At this point, I want a couple of things to happen. First, the server
should be able to match the new revision to the change by following the
replaces references to the commits it already has. Then it should
recognize that this is not a fast forward update to the change and
reject it on those grounds.

After that, John needs to be able to fetch B2 and B3 so that his local
client can perform a merge. I guess John needs to know what change he's
trying to fetch. In this case, he needs to fetch both B2 and B3 in order
get the full history graph of the change. The problem I see here is that
today's git fetch would see B2 and B3 as unrelated branches. There could
be any number of them to fetch. So, how does he ask for everything
related to the change? Does he do a wild card or something?

git fetch codereview refs/changes/123/*

Or does he just fetch all refs (this could be many on a busy review
server)? Or do we need to do something out of band to discover the list
of references that need to be fetched?

I've been thinking out loud a bit. I guess this could be a path forward.
I guess to make gc happy, I've got to keep around a ref pointing at each
new revision so that it doesn't get garbage collected.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote:
> Here's another potential use case.  The stable kernels (e.g., 3.18.y,
> 4.4.y, 4.9.y, etc.) have cherry picks from the the upstream kernel,
> and this is handled by putting in the commit body something like this:
> 
> [ Upstream commit 3a4b77cd47bb837b8557595ec7425f281f2ca1fe ]

I think replaces could apply to cherry picks like this too. The more I
think about it, I actually think that replaces isn't a bad name for it
in the cherry pick context. When you cherry pick a commit, you create a
new commit that is derived from it and stands in for or replaces it in
the new context. It is a stretch but I don't think it is that bad.

You can tell that it is a cherry pick because the referenced commit's
history is not reachable in the current context.

Though we could consider some different names like "derivedfrom",
"obsoletes", "succeeds", "supersedes", "supplants"

> 
> 
> And here's yet another use case.  For internal Google kernel
> development, we maintain a kernel that has a large number of patches
> on top of a kernel version.  When we backport an upstream fix (say,
> one that first appeared in the 4.12 version of the upstream kernel),
> we include a line in the commit body that looks like this:
> 
> Upstream-4.12-SHA1: 5649645d725c73df4302428ee4e02c869248b4c5
> 
> This is useful, because when we switch to use a newer upstream kernel,
> we need make sure we can account for all patches that were built on
> top of the 3xx kernel (which might have been using 4.10, for the sake
> of argument), to the 4xx kernel series (which might be using 4.15 ---
> the version numbers have been changed to protect the innocent).  This
> means going through each and every patch that was on top of the 3xx
> kernel, and if it has a line such as "Upstream 4.12-SHA1", we know
> that it will already be included in a 4.15 based kernel, so we don't
> need to worry about carrying that patch forward.

Are 3xx and 4xx internal version numbers? If I understand correctly, in
your example, 3xx is the heavily patched internal kernel based on 4.10
and 4xx is the internal patched version of 4.15. I think I'm following
so far.

Let's say that you used a "replaces" reference instead of your
"Upstream-4.12-SHA1" reference. The only piece of metadata that is
missing is the "4.12" of your string. However, you could replicate this
with some set arithmetic. If the sha1 referred to by "replaces" exists
in the set of commits reachable from 4.15 then you've answered the same
question.

> In other cases, we might decide that the patch is no longer needed.
> It could be because the patch has already be included upstream, in
> which case we might check in a commit with an empty patch body, but
> whose header contains something like this in the 4xx kernel:
> 
> Origin-3xx-SHA1: fe546bdfc46a92255ebbaa908dc3a942bc422faa
> Upstream-Dropped-4.11-SHA1: d90dc0ae7c264735bfc5ac354c44ce2e

So, the first reference is the old commit that patched the 3xx series?
What is the second reference? What is "4.11" indicating? Is that the
patch that was included in the upstream kernel that obsoleted your 3xx
patch?

If I understood that correctly. You could use a "replaces" reference for
the first line and the second line would still have to be included as a
separate header in your commit message? Does this mean "replaces" is not
useful in your case? I don't think so.

> Or we could decide that the commit is no longer no longer needed ---

no longer no longer needed? Is this a double negative indicating that it
is needed again? Or, is it a mistake?

> perhaps because the relevant subsystem was completely rewritten and
> the functionality was added in a different way.  Then we might have
> just have an empty commit with an explanation of why the commit is no
> longer needed and the commit body would have the metadata:
> 
> Origin-Dropped-3xx-SHA1: 26f49fcbb45e4bc18ad5b52dc93c3afe

The metadata in this reference indicates that it was dropped since 3xx.
Doesn't the empty body (and maybe a commit message saying dropping a
patch) indicate this if a "references" pointer were used instead? The
3xx part of the metadata could be derived again by set arithmetic.

> Or perhaps the commit is still needed, and for various reasons the
> commit was never upstreamed; perhaps because it's only useful for
> Google-specific hardware, or the patch was rejected upstream.  The we
> will have a cherry-pick that would include in the body:
> 
> Origin-3xx-SHA1: 8f3b6df74b9b4ec3ab615effb984c1b5

Replaces reference and set arithmetic.

> (Note: all commits that are added in the rebase workflow, even the
> empty commits that just have the Origin-Dropped-3xx-SHA1 or
> Upstream-Droped-4.11-SHA1 headers, are patch reviewed through Gerrit,
> so we have an audited, second-engineer review to make sure each commit
> in the 3xx kernel that Google had been carrying had the correct
> disposition when rebasing to the 4xx kernel.)

This is 

Re: Bring together merge and rebase

[Carl Baldwin]

On Tue, Dec 26, 2017 at 01:08:45PM +0900, Mike Hommey wrote:
> FWIW, your proposal has a lot in common (but is not quite equivalent)
> to mercurial's obsolescence markers and changeset evolution features.

I've had experience with mercurial but not since about 2009. After
reading up a little bit on this changeset evolution feature, it looks
very much like what I'm proposing. Obsolescence markers look a lot like
replaces references except, as illustrated by this blog [1], they point
the other way! Hence, the illustrations confused me for a moment. It
seems more natural to embed the reference in the new commit pointing at
the old. That said, the illustrated direction of the arrows doesn't
really affect the usefulness of the idea.

His third example (#3-working-with-other-people), appears to be the kind
of collaboration that I'm trying to describe here. To quote the blog:

  In git or vanilla (no extension) mercurial, you would have to figure
  out that b’ and b” are two new versions of b and merge them. Changeset
  evolution detects that situation, marks b’ and b” as being divergent.
  It then suggests automatic resolution with a merge and preserves
  history.

This is the kind of thing that I had to deal with manually in gerrit. I
hadn't seen this feature in mercurial but I'm glad to know now there is
a precedent for it.

Carl

[1] https://blog.laurentcharignon.com/post/2016-02-02-changeset-evolution/

Re: Bring together merge and rebase

[Carl Baldwin]

On Tue, Dec 26, 2017 at 03:19:02PM -0500, Paul Smith wrote:
> As someone working in an environment where we do a lot of rebasing and
> very little merging, I read these proposals with interest.  I'm not
> convinced that we would switch to using a "replaces"-type feature, but
> I'm pretty sure that the "null-merge and rebase" trick described
> previously would not be something we're interested in using.

In the near term, maybe. I'm still working with it to be sure I
understand it right.

> Although "git log" doesn't follow these merges (unless requested), all
> the graphical tools that are used to display history WOULD show all
> those branches.  In a "replaces"-type environment I think the point is
> that we would not want to see them (certainly not by default) as they
> would be used mainly for deeper spelunking, but since they just seem
> like normal merges I don't see any way to turn them off.

You've touched on some of my concerns with the null-merge approach. I
want the end result to be as clean as possible which I think is what
lures many to the rebase methodology in the first place.

> If "replaces" was a separate capability then it could be treated
> differently by history browsing tools, and shown or not shown as
> desired.  For example, a commit that had a "replaces" element could be
> selected somehow and you could expand that set of commits that were
> replaced, or something like that.

Exactly!

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Tue, Dec 26, 2017 at 01:04:36PM -0500, Theodore Ts'o wrote:
> On Mon, Dec 25, 2017 at 06:16:40PM -0700, Carl Baldwin wrote:
> > At this point, you might wonder why I'm not proposing to simply add a
> > "change-id" to the commit object. The short answer is that the
> > "change-id" Gerrit uses in the commit messages cannot stand on its own.
> > It depends on data stored on the server which maintains a relationship
> > of commits to a review number and a linear ordering of commits within
> > the review (hopefully I'm not over simplifying this). The "replaces"
> > reference is an attempt to make something which can stand on its own. I
> > don't think we need to solve the problem of where to keep comments at
> > this point.
> 
> I strongly disagree, and one way to see that is by doing a real-life
> experiment.  If you take a look at a gerrit change that, which in my
> experience can have up to ten or twelve revisions, and strip out the
> comments, so all you get to look at it is half-dozen or more
> revisions.  How useful is it *really*?  How does it get used in
> practice?  What development problem does it help to solve?

I didn't mean to imply that we need to get along without the comments. I
was only pointing out that gerrit, github, other code review UIs have
already figured out how to store comments archored to specific revisions
of files in the repository. I'm suggesting that we let them continue to
do that part while we take the first step of specifying how the
intermediate revisions are kept.

If the various code review servers adopted this then we'd have a client
side which could push up revisions for review to any of them. In
addition, they'd all get the collaborative functionality that I
described in my reply to your previous message.

What we get with this proposal is if I push up a review and that review
is changed by someone (maybe even me) outside of my original workspace,
my client gives me the tools to detect it and merge with it. If I try to
push over (clobber) that work then I get an error that the remote cannot
be fast-forwarded and I'm forced to fetch it and merge it.

I get this while using the rebase methodology I've grown to enjoy having
since using gerrit and I end up with a mainline history that looks
exactly the way I want it to.

> And when you say that it is a bug that the Gerrit Change-Id does not
> stand alone, consider that it can also be a *feature*.  If you keep
> all of this in the main repo, the number of commits can easily grow by
> an order of magnitude.  And these are commits that you have to keep
> forever, which means it slows down every subsequent git clone, git gc
> operation, git tag --contains search, etc.

I didn't say it was a bug; just that it is at odds with what I'm hoping
to do.

I agree that the number of commits in the repository will go up.
However, I think there will be ways to mitigate the costs.

The commits are not in the mainline history. So, I wouldn't expect a git
tag --contains or most other commands that traverse history to consider
them at all.

It could be possible to make the default git clone skip them all and
only fetch them on demand for specific changes.

> So what are the benefits, and what are the costs?  If the benefits
> were huge, then perhaps it would be worthwhile.  But if you lose a
> huge amount of the value because you are missing the *why* between the
> half-dozen to dozen past revisions of the commit, then is it really
> worth it to adopt that particular workflow?
> 
> It seems to me your argument is contrasting a "replaces" pointer
> versus the github PR.  But compared to the Gerrit solution, I don't
> think the "replaces" pointer proposal is as robust or as featureful.
> Also, please keep in mind that just because it's in core git doesn't
> guarantee that Github will support it.  As far as I know github has
> zero support notes, for example.

What I propose is that gerrit and github could end up more robust,
featureful, and interoperable if they had this feature to build from.

With gerrit specifically, adopting this feature would make the "change"
concept richer than it is now because it could supersede the change-id
in the commit message and allow a change to evolve in a distributed
non-linear way with protection against clobbering work.

I have no intention to disparage either tool. I love them both. They've
both made my career better in different ways. I know there is no
guarantee that github, gerrit, or any other tool will do anything to
adopt this. But, I'm hoping they are reading this thread and that they
recognize how this feature can make them a little bit better and jump in
and help. I know it is a lot to hope for but I think it could be great
if it happened.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Tue, Dec 26, 2017 at 06:49:56PM +0100, Ævar Arnfjörð Bjarmason wrote:
> New headers should be added after existing headers, but other than
> that it won't choke on it. See 4b2bced559 when the encoding header was
> added, this also passes most tests:
> 
> diff --git a/commit.c b/commit.c
> index cab8d4455b..cd2bafbaa0 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -1565,6 +1565,8 @@ int commit_tree_extended(const char *msg, size_t 
> msg_len,
> if (!encoding_is_utf8)
> strbuf_addf(, "encoding %s\n", 
> git_commit_encoding);
> 
> +   strbuf_addf(, "replaces 
> \n");
> +
> while (extra) {
> add_extra_header(, extra);
> extra = extra->next;
> 
> Only "most" since of course this changes the sha1 of every commit git
> creates from what you get now.
> 
> > Even if core git code does not simply choke on it, I would like push and
> > pull to follow these pointers and transfer the history behind them. I
> > assumed that git would not do this today. I would also like gc to
> > preserve e8aa79baf6 as if it were referenced by a parent pointer so that
> > it doesn't purge it from the history.
> 
> It won't pay any attention to them if "replaces" is something entirely
> new, what I was pointing out in my earlier reply is that you can simply
> *also* create the parent pointers to these no-op merge commits that hide
> away the previous history the "replaces" headers will be referencing.
> 
> The reason to do that is 100% backwards compatibility, and and only
> needing to make minor UI changes to have this feature (to e.g. history
> walking), as opposed to needing to hack everything that now follows
> "parent" or constructs a commit graph.

Thank you for clarifying this. I have learned something.

> Sure, it could be opt in, be a new format etc. But you haven't
> explained why you think a feature like this would need to rely on an
> entirely new parent structure and side-DAG, as opposed to just the
> more minor changes I'm pointing out above, and which I think will give
> you what you need from a UX level.

I have not wrapped my head around it enough to convince myself that it
gives what I'm after. Let me spend a little more time with it to get a
feel for it.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote:
> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin <c...@ecbaldwin.net> wrote:
> > Anyway, now I am compelled to use github which is also a fine tool and I
> > appreciate all of the work that has gone into it. About 80% of the time,
> > I rebase and force push to my branch to update a pull request. I've come
> > to like the end product of the rebase workflow. However, github doesn't
> > excel at this approach. For one, it doesn't preserve older revisions
> > which were already reviewed which makes it is difficult for reviewers to
> > pick up where they left off the last time. If it preserved them, as
> > gerrit does, the reviewer can compare a new revision with the most
> > recent older revision they reviewed to see just what has been addressed
> > since then.
> 
> A bit of a tangent here, but a thought I didn't wanna lose: In the
> general case where a patch was rebased and the original parent pointer
> was changed, it is actually quite hard to show a diff of what changed
> between versions.
>
> The best I've found is to do something like a 4-way --cc merge diff,
> which mostly works, but has a few awkward cases, and ends up usually
> showing double ++ and -- notation.
>
> Just something I've thought about a fair bit, trying to come up with
> some good way to show "what changed between A1 and A2, but ignore all
> changes between parent P1 and P2 which you don't care that much about
> in this context.

I ran into this all the time with gerrit. I wrote a script that you'd
run on a working copy (with no local changes). I'd fetch and checkout
the latest patchset that I want to review(say, for example, its patchset
5) from gerrit. Then, say I wanted to compare it with patch set 3 which
has a different parent. I'd run this from the top level of my working
copy.

compare-to-previous-patchset 3

It would fetch patch set 3 from gerrit, rebase it to the same parent as
the current patch set on a detached HEAD and then git diff it with the
current patch set. If there were conflicts, it would just commit the
conflict markers to the commit. There is no attempt to resolve the
conflicts. The script was crude but it helped me out many times and it
was nice to be able to review how conflicts were resolved when those
came up.

Carl

PS In case you're curious, here's my script...

#!/bin/bash

remote=gerrit
previous_patchset=$1; shift

# Assumes we're sitting on the latest patch set.
new_patch_set_id=$(git rev-parse HEAD)

branch=$(git branch | awk '/^\*/ {print$2}')
[ "$branch" = "(no" ] && branch=

# set user, host, port, and project from git config
eval $(echo "$(git config remote.$remote.url)" |
   sed 's,ssh://\(.*\)@\(.*\):\([[:digit:]]*\)/\(.*\).git,user=\1 host=\2 p<

gerrit() {
ssh $user@$host -p $port gerrit ${1+"$@"}
}

# Grabs a bunch of information from gerrit about the current patch
eval $(gerrit query --current-patch-set $new_patch_set_id |
awk '
BEGIN {mode="main"}
/ currentPatchSet:/ { mode="currentPatchSet" }
/ ref:/ { printf "new_patch_ref=%s\n", $2 }
/ number:/ {
if (mode=="main") {
printf "review_num=%s\n", $2
}
if (mode=="currentPatchSet") {
printf "new_patchset=%s\n", $2
}
}
')

# Fetch the old patch set
old_patch_ref=${new_patch_ref%$new_patchset}$previous_patchset
git fetch $remote $old_patch_ref && git checkout FETCH_HEAD

# Rebase the old patch set to the parent of the new patch set.
if ! git rebase HEAD^ --onto ${new_patch_set_id}^
then
git diff --name-only --diff-filter=U -z | xargs -0 git add
git rebase --continue
fi

previous_patchset_rebased=$(git rev-parse HEAD)

# Go back to the new patch set and diff it against the rebased old one.
if [ "$branch" ]
then
git checkout $branch
else
git checkout $new_patch_set_id
fi
git diff $previous_patchset_rebased

Re: Bring together merge and rebase

[Carl Baldwin]

On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote:
> As a suggestion, before diving into the technical details of your
> proposal, it might be useful consider the usage scenario you are
> targetting.  Things like "git rebase" and "git merge" and your
> proposed "git replace/replay" are *mechanisms*.
> 
> But how they fit into a particular workflow is much more important
> from a design perspective, and given that there are many different git
> workflows which are used by different projects, and by different
> developers within a particular project.
> 
> For example, rebase gets used in many different ways, and many of the
> debates when people talk about "git rebase" being evil generally
> presuppose a particular workflow that that the advocate has in mind.
> If someone is using git rebase or git commit --amend before git
> commits have ever been pushed out to a public repository, or to anyone
> else, that's a very different case where it has been visible
> elsewhere.  Even the the most strident, "you must never rewrite a
> commit and all history must be preserved" generally don't insist that
> every single edit must be preserved on the theory that "all history is
> valuable".
> 
> > The git history now has two dimensions. The first shows a cleaned up
> > history where fix ups and code review feedback have been rolled into
> > the original changes and changes can possibly be ordered in a nice
> > linear progression that is much easier to understand. The second
> > drills into the history of a change. There is no loss and you don't
> > change history in a way that will cause problems for others who have
> > the older commits.
> 
> If your goal is to preserve the history of the change, one of the
> problems with any git-centric solution is that you generally lose the
> code review feedback and the discussions that are involved with a
> commit.  Just simply preserving the different versions of the commits
> is going to lose a huge amount of the context that makes the history
> valuable.
> 
> So for example, I would claim that if *that* is your goal, a better
> solution is to use Gerrit, so that all of the different versions of
> the commits are preserved along with the line-by-line comments and
> discussions that were part of the code review.  In that model, each
> commit has something like this in the commit trailer:
> 
> Change-Id: I8d89b33683274451bcd6bfbaf75bce98

Thank you for your reply. I agree that discussing the workflows is very
valuable and I certainly haven't done that justice yet.

Gerrit is the tool that got me thinking about my proposal in the first
place. I spent a few years developing and doing a significant number of
code reviews using it. I've since changed to an environment where I no
longer have it. It turns out that "a better solution is to use Gerrit"
is not helpful to me now because it isn't up to me. Gerrit is not nearly
as ubiquitous as git itself.

In my opinion, Gerrit has shown us the power of the "change". As you
point out, it introduced the change-id embedded into the commit message
and uses it to track a change's progress as a "review." I think these
are powerful concepts and Gerrit did a nice job with them. I guess one
of my goals with my proposal here is to formalize the "change" idea so
that any git-based tool understands it and can interoperate. This is why
I want it in the core git commit object and I want push, pull, gc, and
other commands to understand it.

At this point, you might wonder why I'm not proposing to simply add a
"change-id" to the commit object. The short answer is that the
"change-id" Gerrit uses in the commit messages cannot stand on its own.
It depends on data stored on the server which maintains a relationship
of commits to a review number and a linear ordering of commits within
the review (hopefully I'm not over simplifying this). The "replaces"
reference is an attempt to make something which can stand on its own. I
don't think we need to solve the problem of where to keep comments at
this point.

An unbroken chain of "replaces" references obviates the need for the
change id in the commit message. From any given commit in the chain, we
can follow the references to the first commit which started the review.
However, the chain is even more useful because it is not limited to a
linear progression of revisions. Let me try to explain how this can
solve some of the most common issues I ran into with the rebase type
workflow.

Look at what happens in a rebase type workflow in any of the following
scenarios. All of these came up regularly in my time with Gerrit.

1. Make a quick edit through the web UI then later work on the
   change again in your local clone. It is easy to forget to pull
   down the change made through the UI before starting to work on it
   again. If that happens, the change made through the UI will
   almost certainly be clobbered.

2. You or someone else creates a second change that is dependent on

Re: Bring together merge and rebase

[Carl Baldwin]

On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> But I don't see why you think this needs a new "replaces" parent
> >> pointer orthagonal to parent pointers, i.e. something that would
> >> need to be a new field in the commit object (I may have misread the
> >> proposal, it's not heavy on technical details).
> >
> > Just to clarify, I am proposing a new "replaces" pointer in the commit
> > object. Imagine starting with rebase exactly as it works today. This new
> > field would be inserted into any new commit created by a rebase command
> > to reference the original commit on which it was based. Though, I'm not
> > sure if it would be better to change the behavior of the existing rebase
> > command, provide a switch or config option to turn it on, or provide a
> > new command entirely (e.g. git replay or git replace) to avoid
> > compatibility issues with the existing rebase.
> 
> Yeah that sounds fine, I thought you meant that this "replaces" field
> would replace the "parent" field, which would require some rather deep
> incompatible changes to all git clients.
> 
> But then I don't get why you think fetch/pull/gc would need to be
> altered, if it's because you thought that adding arbitrary *new* fields
> to the commit object would require changes to those that's not the case.

Thank you again for your reply. Following is the kind of commit that I
would like to create.

tree fcce2f309177c7da9c795448a3e392a137434cf1
parent b3758d9223b63ebbfbc16c9b23205e42272cd4b9
replaces e8aa79baf6aef573da930a385e4db915187d5187
author Carl Baldwin <c...@ecbaldwin.net> 1514057225 -0700
committer Carl Baldwin <c...@ecbaldwin.net> 1514058444 -0700

What will happen if I create this today? I assumed git would just choke
on it but I'm not certain. It has been a long time since I attempted to
get into the internals of git.

Even if core git code does not simply choke on it, I would like push and
pull to follow these pointers and transfer the history behind them. I
assumed that git would not do this today. I would also like gc to
preserve e8aa79baf6 as if it were referenced by a parent pointer so that
it doesn't purge it from the history.

I'm currently thinking of an example of the workflow that I'm after in
response to Theodore Ts'o's message from yesterday. Stay tuned, I hope
it makes it clearer why I want it this way.

[snip]

> Instead, if I understand what you're actually trying to do, it could
> also be done as:
> 
>  1) Just add a new replaces  field to new commit objects
> 
>  2) Make git-rebase know how to write those, e.g. add two of those
> pointing to A & B when it squashes them into AB.
> 
>  3) Write a history traversal mechanism similar to --full-history
> that'll ignore any commits on branches that yield no changes, or
> only those whose commits are referenced by this "replaces" field.
> 
> You'd then end up with:
> 
>  A) A way to "stash" these commits in the permanent history
> 
>  B) ... that wouldn't be visble in "git log" by default
> 
>  C) Would require no underlying changes to the commit model, i.e. it
> would work with all past & future git clients, if they didn't know
> about the "replaces" field they'd just show more verbose history.

I get this point. I don't underestimate how difficult making such a
change to the core model is. I know there are older clients which cannot
simply be updated. There are also alternate implementations (e.g. jgit)
that also need to be considered. This is the thing I worry about the
most. I think at the very least, this new feature will have to be an
opt-in feature for teams who can easily ensure a minimum version of git
will be used. Maybe the core.repositoryformatversion config or something
like that would have to play into it. There may also be some minimal
amount that could be backported to older clients to at least avoid
choking on new repos (I know this doesn't guarantee older clients will
be updated). Just throwing a few ideas out.

I want to be sure that the implications have been explored before giving
up and doing something external to git.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote:
> Hi Carl,
> 
> On Sat, 23 Dec 2017, Carl Baldwin wrote:
> 
> > I imagine that a "git commit --amend" would also insert a "replaces"
> > reference to the original commit but I failed to mention that in my
> > original post.
> 
> And cherry-pick, too, of course.

This brings up a good point. I do think this can be applied to
cherry-pick, but as someone else pointed out, the name "replaces"
doesn't seem right in the context of a cherry-pick. So, maybe "replaces"
is not the right name. I'm open to suggestions.

It occurs to me now that the reason that I want a separate, orthogonal
history dimension is that a "replaces" reference does not imply that the
referenced commit is pulled in with all of its history like a "parent"
reference does. It isn't creating a merge commit. It means that the
referenced commit is derived from the other one and, at least in the
context of this branch's main history, renders it obsolete. Given this
definition, I think it applies to a cherry-pick.

> Both of these examples hint at a rather huge urge of some users to turn
> this feature off because the referenced commits may very well be
> throw-away commits in their case, making the newly-recorded information
> completely undesired.

I certainly don't want to make it difficult to get rid of throw-away
commits.

The workflows I'm interested in are mostly around iterating on what will
end up looking like a single commit in the final history. I'm imagining
posting a change, (or changes) somewhere to be reviewed by others.
Others submit feedback and I continue iterating given the feedback. If
certain intermediate throw-away commits have only been seen locally by
the author, they could be squashed into a single minimal new update.

I'm diving deeper into these workflows in my reply to Theodore. To avoid
fragmenting my ideas too much, I'll take the details over to that reply.
I hope to finished that soon.

Carl

Re: Bring together merge and rebase

[Carl Baldwin]

On Sat, Dec 23, 2017 at 05:19:35PM -0500, Randall S. Becker wrote:
> No matter how this plays out, let's please make very sure to provide
> sufficient user documentation so that those of us who have to explain
> the differences to users have a decent reference. Even now, explaining
> rebase vs. merge is difficult enough for people new to git to choose
> which to use when (sometimes pummeling is involved to get the point
> across  ), even though it should be intuitive to most of us. I am
> predicting that adding this capability is going to further confuse the
> *new* user community a little. Entirely out of enlighted
> self-interest, I am offering to help document
> (edits/contribution//whatever) this once we get to that point in
> development.

I agree. I have a feeling that it may take a while for this to play out.
This has been on my mind for a while and think there will be some more
discussion before anything gets started.

Carl

> Something else to consider is how (or if) this capability is going to
> be presented in front-ends and in Cloud services. GitK is a given, of
> course. I'm still impatiently waiting for worktree support from some
> other front-ends.

It all takes time. :)

> Cheers,
> Randall
> 
> -- Brief whoami: NonStop developer since approximately 
> UNIX(421664400)/NonStop(2112884442)
> -- In my real life, I talk too much.

Re: Bring together merge and rebase

[Carl Baldwin]

 on the branch they got merged
> into. I don't know about bisect, but if it's not doing something similar
> already it would be easy to make it do so.

I haven't had the need to use --full-history much. Let me see if I can
play around with it to see if I can figure out how to use it in a way
that gives me what I'm after.

> You could even add a new field to the commit object of A2+B2 & C2 which
> would be one or more of "replaces ", commit objects
> support adding arbitrary new fields without anything breaking.
> 
> But most importantly, while I think this gives you the same things from
> a UX level, it doesn't need any changes to fetch, push, gc or whatever,
> since it's all stuff we support today, someone just needs to hack
> "rebase" to create this sort of no-op merge commit to take advantage of
> it.

Avoiding changes would be very nice. I'm not convinced yet that it can
be done but maybe when I understand your counter proposal, it will
become clearer.

Thank you,
Carl Baldwin

Bring together merge and rebase

[Carl Baldwin]

The big contention among git users is whether to rebase or to merge
changes [2][3] while iterating. I used to firmly believe that merging
was the way to go and rebase was harmful. More recently, I have worked
in some environments where I saw rebase used very effectively while
iterating on changes and I relaxed my stance a lot. Now, I'm on the
fence. I appreciate the strengths and weaknesses of both approaches. I
waffle between the two depending on the situation, the tools being
used, and I guess, to some extent, my mood.

I think what git needs is something brand new that brings the two
together and has all of the advantages of both approaches. Let me
explain what I've got in mind...

I've been calling this proposal `git replay` or `git replace` but I'd
like to hear other suggestions for what to name it. It works like
rebase except with one very important difference. Instead of orphaning
the original commit, it keeps a pointer to it in the commit just like
a `parent` entry but calls it `replaces` instead to distinguish it
from regular history. In the resulting commit history, following
`parent` pointers shows exactly the same history as if the commit had
been rebased. Meanwhile, the history of iterating on the change itself
is available by following `replaces` pointers. The new commit replaces
the old one but keeps it around to record how the change evolved.

The git history now has two dimensions. The first shows a cleaned up
history where fix ups and code review feedback have been rolled into
the original changes and changes can possibly be ordered in a nice
linear progression that is much easier to understand. The second
drills into the history of a change. There is no loss and you don't
change history in a way that will cause problems for others who have
the older commits.

Replay handles collaboration between multiple authors on a single
change. This is difficult and prone to accidental loss when using
rebase and it results in a complex history when done with merge. With
replay, collaborators could merge while collaborating on a single
change and a record of each one's contributions can be preserved.
Attempting this level of collaboration caused me many headaches when I
worked with the gerrit workflow (which in many ways, I like a lot).

I blogged about this proposal earlier this year when I first thought
of it [1]. I got busy and didn't think about it for a while. Now with
a little time off of work, I've come back to revisit it. The blog
entry has a few examples showing how it works and how the history will
look in a few examples. Take a look.

Various git commands will have to learn how to handle this kind of
history. For example, things like fetch, push, gc, and others that
move history around and clean out orphaned history should treat
anything reachable through `replaces` pointers as precious. Log and
related history commands may need new switches to traverse the history
differently in different situations. Bisect is a interesting one. I
tend to think that bisect should prefer the regular commit history but
have the ability to drill into the change history if necessary.

In my opinion, this proposal would bring together rebase and merge in
a powerful way and could end the contention. Thanks for your
consideration.

Carl Baldwin

[1] http://blog.episodicgenius.com/post/merge-or-rebase--neither/
[2] https://git-scm.com/book/en/v2/Git-Branching-Rebasing
[3] http://changelog.complete.org/archives/586-rebase-considered-harmful

Re: [PATCH] unset CDPATH in git-clone

[Carl Baldwin]

On Mon, Sep 05, 2005 at 12:37:58PM -0700, Junio C Hamano wrote:
 Carl Baldwin [EMAIL PROTECTED] writes:
 
  The function get_repo_base seems to break with this CDPATH.
 
 Sorry, your message somehow slipped my filtering.  Thanks for
 the analysis.  Of course, CDPATH would break it.
 
 Is there any good reason why somebody would want to have CDPATH
 in his environment, inherited to be used by any shell scripts,
 as opposed to have it as a plain shell variable that is set only
 in interactive shells?  I do not think of any.

Good point.  There is no good reason at all.  It happens when one does
not know the difference between a plain shell variable and an
environment variable.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

[PATCH] unset CDPATH in git-clone

[Carl Baldwin]

Hello,

A colleague was having problems with git clone.  It seemed to work as
expected for me so I went into his environment to see what was causing
it to fail.  I found that he had set the CDPATH environment variable to
something like '.:..:../..:$HOME'.  Try this (using bash) and you'll see
the problem:

export CDPATH=.
git clone (anything local)

The function get_repo_base seems to break with this CDPATH.

Below is how I solved the problem for the short-term.  Use it as you see
fit.  I did not look into other commands to see if there are other
implications to using CDPATH.

Cheers,
Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---

 git-clone-script |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

50e48b03a5a82bb1e4ca95ef4e04cafc39a96f79
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -5,6 +5,8 @@
 # 
 # Clone a repository into a different directory that does not yet exist.
 
+unset CDPATH
+
 usage() {
echo 2 * git clone [-l [-s]] [-q] [-u upload-pack] repo dir
exit 1
-
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

Re: [RFC] undo and redo

[Carl Baldwin]

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 BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: [RFC] undo and redo

[Carl Baldwin]

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 BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: [RFC] undo and redo

[Carl Baldwin]

Oops.  I forgot to actually exit from the script if git-diff-files is
non-empty.

Also, looking at it now, I don't think keeping undo information in a
stack is the right thing.  But keeping more than just one would be good.
Oh well, my first shot is never perfect.  ;-)

Carl

On Wed, Aug 24, 2005 at 11:23:39AM -0600, Carl Baldwin wrote:
 Hello,
 
 So, one thing that I liked about GNU Arch when I tried it out was the
 ability to undo and redo changes in the local working copy.  I decided
 to try to do this with git.  What I have is preliminary.  I'm sure it
 could use some work.
 
 So, I started with the assumption that all changes in the working copy
 have been updated to the cache.  My scripts check this (with
 git-diff-files) and abort if this is not the case.
 
 Undo calls git-write-tree to write the changes to the object store.  It
 stores that tree's hash and the current HEAD's tree's hash in a file.
 Then it reverts the working copy to HEAD.
 
 Redo grabs these two trees from the file, does git-write-tree to produce
 a third tree and merges the three using the old HEAD's tree as the base
 of the merge.  This way, new commits can happen and the local copy can
 be modified since the undo and it should still work assuming no
 conflicts emerge.
 
 Attached are the two scripts.  Comments and criticism are welcome.
 
 Cheers,
 Carl
 
 -- 
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Carl BaldwinSystems VLSI Laboratory
  Hewlett Packard Company
  MS 88   work: 970 898-1523
  3404 E. Harmony Rd. work: [EMAIL PROTECTED]
  Fort Collins, CO 80525  home: [EMAIL PROTECTED]
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 #!/bin/sh
 
 . git-sh-setup-script || die Not a git archive
 
 if [ -n $(git-diff-files) ]; then
 echo The following files should be updated!
 echo
 git-diff-files | awk '{print $6}'
 fi
 
 undostack=$GIT_DIR/undostack
 
 if [ ! -s $undostack ]; then
 echo No undo information in $undostack
 else
 # Read the top of the stack
 basetree=$(cat $undostack | tail -n 2 | head -n 1)
 redotree=$(cat $undostack | tail -n 1)
 
 # Pop the stack
 cat $undostack | head -n -2  $undostack.tmp
 mv $undostack{.tmp,}
 
 currenttree=$(git-write-tree)
 
 git-read-tree -u -m $basetree $currenttree $redotree
 git-merge-cache git-merge-one-file-script -a
 fi

 #!/bin/sh
 
 . git-sh-setup-script || die Not a git archive
 
 if [ -n $(git-diff-files) ]; then
 echo The following files should be updated!
 echo
 git-diff-files | awk '{print $6}'
 fi
 
 undostack=$GIT_DIR/undostack
 
 headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | head -n 1 | sed -e 
 's/tree //')
 undotree=$(git-write-tree)
 
 if [ $headtree == $undotree ]; then
 echo There are no changes to undo.
 else
 {
echo $headtree
echo $undotree
 }  $undostack
 
 echo Saved current state as tree $undotree.
 echo Reverting to HEAD, $headtree...
 
 git-checkout-script -f
 fi


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: [RFC] undo and redo

[Carl Baldwin]

On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote:
 
 
 On Wed, 24 Aug 2005, Carl Baldwin wrote:
 
  Oops.  I forgot to actually exit from the script if git-diff-files is
  non-empty.
  
  Also, looking at it now, I don't think keeping undo information in a
  stack is the right thing.  But keeping more than just one would be good.
  Oh well, my first shot is never perfect.  ;-)
 
 I would actually argue that
 
   git checkout -b newbranch undo-point
 
 is the perfect undo.

Yes, this does the job nicely.  I've used it like this effectively.  I
meant for undo/redo to be a lighter weight way of moving (uncommitted)
changes out of the way briefly and then replaying them onto the working
directory later.

 It leaves the old state in the old branch, and creates a new branch (and
 checks it out) with the state you want to revert to. The advantage is
 exactly that there is no stack of undo's: you can have multiple
 independent undo's pending, and you can continue development at any of 
 them. And merge the results together.

The stack was the wrong thing to do.  I think I would have undo pick a
name like undo-1, undo-2 etc.  Or something like that.  redo would pick
the most recent unless told to do otherwise.

A possible advantage of undo is having the freedom to stay on the
current branch or switch to another.

 Of course, right now we don't have a delete branch command, but it's 
 really as simple as

   rm .git/refs/heads/branchname
 
 (and eventually you may want to do a git prune to get rid of stale
 objects, but that's a separate issue).
 
   Linus
 

This brings up a good point (indirectly).  git prune would destroy the
undo objects.  I had thought of this but decided to ignore it for the
time being.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: [RFC] undo and redo

[Carl Baldwin]

On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote:
 Carl Baldwin [EMAIL PROTECTED] writes:
 
  Attached are the two scripts.  Comments and criticism are welcome.
 
 An obligatory non-technical comment.  I would have liked to see
 this not in a MIME multipart format, which made commenting on it
 a bit harder than necessary.
 
  Content-Type: text/plain; charset=us-ascii
  Content-Disposition: attachment; filename=git-undo-script
 
  #!/bin/sh
 
  . git-sh-setup-script || die Not a git archive
 
  if [ -n $(git-diff-files) ]; then
  echo The following files should be updated!
  echo
  git-diff-files | awk '{print $6}'
  fi
 
 There is nothing wrong with the above, but I would have written
 it like this (I think you forgot to exit after showing the list
 of files):
 
 git-update-cache --refresh || exit

I'll take this.  This is what I was going for but being new to git I
didn't know all that was available.  A good reason to request comments
:-)

 Also nice to learn here is git-diff-files --name-only.

Also good to know, thanks.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: cg-update/cg-merge refuse to update if state is dirty?

[Carl Baldwin]

Hello,

Here's a thought.  It might be nice, in this situation, to have
something like a git-undo-script that can undo the changes in the index
storing them in a tree object but not wrapping them into a commit.  A
ref to the tree can be stored in an 'undo' file somewhere under .git.
When the merge is done then a git-redo-script can retrieve and merge
that tree back into the index.  This way, cg-{merge,update} could refuse
--- which I tend to think it should --- to merge into a dirty tree but
it wouldn't be so inconvenient.

cogito would handle synchronization with the working copy like normal.

Carl

On Tue, Aug 23, 2005 at 08:09:04PM +1200, Martin Langhoff wrote:
 Should cg-update or cg-merge be refusing to merge if the tree is
 dirty? If there are uncommitted files, and the merge fails, a lot of
 unrelated changes will be dumped on the working tree, which ends up
 with a mix of things.
 
 cheers,
 
 
 martin
 -
 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
 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

[RFC] Removing deleted files after checkout

[Carl Baldwin]

Hello,

I recently started using git to revision control the source for my
web-page.  I wrote a post-update hook to checkout the files when I push
to the 'live' repository.

In this particular context I decided that it was important to me to remove
deleted files after checking out the new HEAD.  I accomplished this by running
git-ls-files before and after the checkout.

Is there a better way?  Could there be some way built into git to easily
find out what files dissappear when replacing the current index with one
from a new tree?  Is there already?  The behavior of git should NOT
change to delete these files but I would argue that some way should
exist to query what files disappeared if removing them is desired.

Here is some code that I wrote for this.  It feels a bit hackish to me but I
couldn't think of anything better.  Comments and criticism are welcome.

#!/bin/sh

# HEAD changed so checkout the new HEAD deleted any files that should no longer
# be around.
oldlist=$(tempfile)
newlist=$(tempfile)
removedlist=$(tempfile)

git-ls-files | sort -r  $oldlist
git-checkout-script -f
git-ls-files | sort -r  $newlist

diff -u $oldlist $newlist |
  tail -n +4 |
  sed -n 's/^-//p'  $removedlist

# Remove each file
cat $removedlist | xargs -rl rm -f
# Remove the directories if empty
cat $removedlist | xargs -rl dirname | xargs -rl rmdir -p 
--ignore-fail-on-non-empty

rm -f $oldlist $newlist $removedlist

# --- snip ---

If you are interested I attached the full post-update hook script that I
actually use to do this.  Again, comments are welcome.

Thanks,
Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh

export PATH=/usr/local/bin:/usr/bin:/bin

# cd to the root of the project directory (assume one dir up from GIT_DIR)
cd $GIT_DIR/..
unset GIT_DIR

# Set up some temporary files and a trap to delete them
oldlist=$(tempfile)
newlist=$(tempfile)
removelist=$(tempfile)
trap rm -f $oldlist $newlist $removelist 0 1 2 3 15

# Get list of files from the current index
git-ls-files | sort -r  $oldlist

# Checkout the index to the working directory
git-checkout-script -f

# Get list of files from the current (new) index
git-ls-files | sort -r  $newlist

# Use diff to determine which files to remove from the working copy
diff -u $oldlist $newlist |
  tail -n +4 |
  sed -n 's/^-//p'  $removelist

cat $removelist | xargs -rl rm -f
cat $removelist | xargs -rl dirname | xargs -rl rmdir -p 
--ignore-fail-on-non-empty

Re: [RFC] Removing deleted files after checkout

[Carl Baldwin]

Ok, the following is what I came up with based on your response.  This
is .git/hooks/update.  It mostly works in my situation.  See below for
my discussion on what didn't work.

#!/bin/sh

export PATH=/usr/local/bin:/usr/bin:/bin

# cd to the root of the project directory (assume one dir up from GIT_DIR)
cd $GIT_DIR/..
unset GIT_DIR

if expr $2 : '0*$' /dev/null; then
git-read-tree --reset $3 
git-checkout-cache -q -f -u -a
else
git-read-tree -m -u $2 $3
fi

exit 0

# --- snip ---

The thing that this doesn't do is remove empty directories when the last
file is deleted.  I once expressed the opinion in a previous thread that
directories should be added and removed explicitly in git.  (Thus
allowing an empty directory to be added).  If this were to happen then
this case would get handled correctly.  However, if git stays with the
status quo then I think that git-read-tree -u should be changed to
remove the empty directory.  This would make it consistent.

What do you think?  Ideas?

Carl

On Tue, Aug 23, 2005 at 02:54:30PM -0700, Junio C Hamano wrote:
 Daniel Barkalow [EMAIL PROTECTED] writes:
 
   If you don't use -f, git-checkout-script removes deleted files. Using -f
   tells it to ignore the old index, which means that it can't tell the
   difference between removed files and files that weren't tracked at all.
 
 Yes and no.  git checkout assumes that the index file and the
 working tree somewhat resembles what is in .git/HEAD commit.
 Since push operation updates .git/HEAD commit without touching
 the index file, that assumption does not hold.
 
 The update hook gets old commit name and new commit name, so you
 should be able to do (untested):
 
 git-read-tree -m -u $old_commit $new_commit
 
 there, of course after making sure that you had old_commit (the
 first time push happens to a new ref you would not have that one).
 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: Making note, in the repository, of push/pull relationships

[Carl Baldwin]

On Mon, Aug 15, 2005 at 05:18:43PM -0700, Junio C Hamano wrote:
 If you are referring to what I said about the user having some
 control over both ends hence it should be possible to arrange to
 use the same name on both ends to reduce mental burden, Pasky
 and others convinced me otherwise during later discussions, and
 the current core knows how to do renaming pushes.

I wasn't referring to any particular post just a general idea that came
up in the thread. I wanted a starting point to present my thoughts. :-)

 $ cat .git/remotes/ko
 URL: master.kernel.org:/pub/scm/git/git.git/
 Push: master pu rc
 Pull: master:ko-master pu:ko-pu rc:ko-rc

This is very close to what I was getting at.  It records each branch
involved and wether the relationship is push or pull (or possibly both).

If I may, let me give an example of something I think could serve the
purpose a little more simply and generically.

Let's say I start with the following:
% ls .git/refs/heads
master
mylocalbranch
myremotebranch
ko-master
% cat .git/branches/ko-master
master.kernel.org:/pub/scm/git/git.git

I would add something like this:  (I didn't put much thought into the
actual directory and file names, forgive me.  ;-)

% cat .git/branches/relationships
pull:ko-master:master
pull:master:mylocalbranch # The next two document my flow locally
pull:mylocalbranch:master
push:master:myremotebranch # I push my master to a remote that I control

_OR_

% ls .git/relationships/*
pull:ko-master:master
pull:master:mylocalbranch
pull:mylocalbranch:master
push:master:myremotebranch

I think this is flexible and could easily support the workflow that you
present below.  You could do the following as a convenience in using
fetch in addition to what I suggest above.

% cat .git/remotes/ko
push: master:ko-master pu:ko-pu rc:ko-rc
pull: ko-master:master ko-pu:pu ko-rc:rc

I might argue that this is now a job for a porcelain script or
something.

With the addition of the simple relationships file a complete graph of
your workflow could derived.  There is no assumption on what the
workflow is nor if the branches are local or remote.  This work flow can
be arbitrarily simple or complex but further complexity can and should
be handled in the porcelains.

 The expected workflow with the above example remotes file is
 for me to be able to do this:
 
  (1) fetch from master.kernel.org (that is the source of the
  mirroring for everybody to see on {www,rsync}.kernel.org)
  before starting my day.  The current git fetch does not
  do this, but make it:
 
  $ git fetch ko

This is still doable.  As is this...

  (2) after doing work in my private repository, push to
  master.kernel.org with:
 
  $ git push ko

 Note that I am _not_ expecting for git push/pull/fetch
 commands to dynamically update .git/remotes/ file whenever it

So, with the way I suggest splitting up refspecs and 'relationships' I
_would_ suggest dynamically adding to (but not deleting from) the
relationships file.  But, I agree with you about the refspec.  I think
this should be 100% supplied by the user or porcelain.

Adding relationships dynamically will be a good way to document whatever
flow is being used.  Also, the savy user can periodically check the file
(or a porcelain with a pretty interface could do something intelligent
with it) to see how his work flow has evolved.  He can also
delete relationships that are no longer needed if he is a clean-freak
like me ;-)

I really think there is some good common ground here.  Let's keep going
with this.  I actually have an idea brewing up for a porcelain to handle
work-flow in a tightly-knit corporate type development environment.

Hey, I've enjoyed the discussion.  I hope to make a valuable
contribution to git.  I think it has incredible potential.

Cheers,
Carl

 would not push usual master pu rc but create a new testing
 branch there, starting at the commit which is the head commit of
 the local pu branch.  This is a one-shot override, so next
 time around, git push ko will do the usual three heads that is
 recorded in the .git/remotes/ko file.
 
 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: Making note, in the repository, of push/pull relationships

[Carl Baldwin]

On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote:
 And presumably you have .git/branches/myremotebranch file that
 says something like master.kernel.org:/pub/scm/git/git.git.
 Or should the last line of relationships file be spelled just
 push:master:ko-master?

Oops, I did intend to add just that to .git/branches/myremotebranch.

  % cat .git/remotes/ko
  push: master:ko-master pu:ko-pu rc:ko-rc
  pull: ko-master:master ko-pu:pu ko-rc:rc
 
  I might argue that this is now a job for a porcelain script or
  something.
 
 Probably.
 
 My primary interest in discussing this is to see Porcelain folks
 agree on what notation and semantics to use, and probably set an
 example by having the minimum base in the barebone Porcelain.

This sounds good.

 Personally I think there are two kinds of patch-flow: one that
 is pretty much static that can easily be described with
 something like your relationships notation, and ad-hoc one that
 I think should not automatically contaminate the established
 static flow your relationships notation nicely describes.  The
 corporate world may put disproportional stress on the importance
 of the former, but my feeling is that ad-hoc patch-flow that is
 outside your usual static patch-flow is just as important; see
 Documentation/howto/using-topic-branches.txt for why.

I don't doubt the utility of these topic branches.  In fact, I think it
what he's doing with this is great.  This is exactly the kind of thing
the 'relationships' could help out with.

As he creates branches from existing branches, pushes, pulls and merges
between them the relationships files would maintain a record of this.
Let's say, for example, he made a change on speed-up-spinlocks and
merged it to test.  Later, a bug is found and he fixes the bug on the
speed-up-spinlocks branch.  Now, a script could run using the
relationships files that could immediately tell that the test branch is
behind the speed-up-spinlocks branch and that they should be merged.
For someone who has a lot of different things to do this will be
valuable.

I would leave maintenance of any static work flows up to the porcelains.
If a project chose to use some sort of static flow then it can simply
populate the relationships files to help drive pushing and pulling if
some rogue developer were to use git alone or some other porcelain (thus
maintaining compatibility between porcelains).  If a porcelain wanted to
be very strict about adherance to a static flow then checking the
relationships could tell if something 'bad' has been done outside of
that porcelain.

I hope I'm being clear.  Please let me know if something is not clear.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: Add an empty directory?

[Carl Baldwin]

Hi,

On Sat, Aug 13, 2005 at 08:00:08PM +0200, Petr Baudis wrote:
 the object databases supports it, but the index file does not. But yes,
 it should be supported, I think.
 
 Some argue that this is useless, so some practical example of its
 usefulness might be a good motivation to get us going. :-)

That's fair.  So, here goes.  I don't particularly condone nor condemn
any of these.

- Just yesterday, I was starting a project at work.  I wanted to add a
  doc directory as a reminder to add documentation very soon.  I could
  not do this.

- I've worked with projects that use an obj, .obj, .obj-platform or
  something resembling this and have checked in this directory to make
  sure it exists for all.  Of course, a build system could be made to
  generate this directory when needed avoiding the need to check it in.

- A common practice I've seen with autotools is to use a config
  subdirectory for many of the autogenerated scripts.  If I'm not
  mistaken older versions would not create this directory if it did not
  already exist.  Checking it in was a convenience.

The bottom line is that I don't really see many situations where it is
absolutely necessary but it is a convenience.  Not supporting it may
seem like an artificial limit that really didn't need to be there.

I'll read up on the index file when I get the chance.

Cheers,
Carl


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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

Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?

[Carl Baldwin]

On Fri, Jul 29, 2005 at 08:10:51AM +, Petr Baudis wrote:
 Exactly. I want much more freedom in pushing, the only requirement being
 that the to-be-replaced remote head is ancestor of the to-be-pushed
 local head. I think (am I wrong?) git-send-pack localhead:remotehead
 would work just fine for me, the only thing I need is the support for
 different local and remote head names.

Greetings,

Sorry to join the game so late.  I've only read this thread now.

It seems to me that this is the way to go.  Several have mentioned that
head names should be the same on the remote and the local side.
However, I wanted to point out that it may be impossible to keep these
names in sync due to the 'loosely knit' nature of the types of projects
that are likely to use git.

It seems that the requirement that the remote head be a strict ancestor
of the local head is actually quite strong and should avoid mistakes
like pushing to the wrong head.

Anyway, those are my two cents.  I couldn't tell wether a resolution had
been achieved so I thought I would pipe up.

Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl BaldwinSystems VLSI Laboratory
 Hewlett Packard Company
 MS 88   work: 970 898-1523
 3404 E. Harmony Rd. work: [EMAIL PROTECTED]
 Fort Collins, CO 80525  home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
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