Re: Bring together merge and rebase
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
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
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
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 > wrote: > > >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin > 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
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 referen
Re: Bring together merge and rebase
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
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
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 great!
Re: Bring together merge and rebase
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
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
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
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(&buffer, "encoding %s\n",
> git_commit_encoding);
>
> + strbuf_addf(&buffer, "replaces
> \n");
> +
> while (extra) {
> add_extra_header(&buffer, 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
On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote:
> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin 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
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
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 1514057225 -0700 committer Carl Baldwin 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
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
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&UNIX developer since approximately > UNIX(421664400)/NonStop(2112884442) > -- In my real life, I talk too much.
Re: Bring together merge and rebase
ify > --full-history, so git already knows to ignore these sort of side > histories that result in no changes 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
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
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
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 ] "
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
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
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" <[EMAIL PROTECTED]> 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 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
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: > > > 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. > > > > > [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
$ 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 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
rom the top of undo-redo branch. > >Your implementation of "redo" can either be (patch way): > >git-diff-tree -p undo-redo~N^ undo-redo~N | git apply --index > >or (merge way): > >git-read-tree -m undo-redo~N^2 undo-redo~N HEAD && >git-merge-cache -o git-merge-one-file-script -a > > (2) Try StGIT. > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
This is interesting. Can a ref be to a tree rather than a commit? And it still works? I guess it would. I hadn't thought about that. Will prune preserve any tree mentioned in any file in refs? How does this work exactly? Cheers, Carl On Wed, Aug 24, 2005 at 04:44:48PM -0400, Daniel Barkalow wrote: > On Wed, 24 Aug 2005, Carl Baldwin wrote: > > > 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. > > If you made undo store the tree under refs somewhere, git prune would > preserve it. > > -Daniel > *This .sig left intentionally blank* > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
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: [RFC] undo and redo
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 > > 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
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
[RFC] undo and redo
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
Re: [RFC] Removing deleted files after checkout
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: [RFC] Removing deleted files after checkout
On Tue, Aug 23, 2005 at 05:27:12PM -0400, Daniel Barkalow wrote: > On Tue, 23 Aug 2005, Carl Baldwin wrote: > > > On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote: > > > On Tue, 23 Aug 2005, Carl Baldwin wrote: > > > > > > > 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. > > > > > > 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. > > > > Maybe I'm doing something wrong. This does not happen for me. > > > > I tried a simple test with git v0.99.4... > > > > cd > > mkdir test-git && cd test-git/ > > echo testing | cg-init > > echo contents > file > > git-add-script file > > git-commit-script -m 'testing' > > [point 1] > > > cd .. > > cg-clone test-git/.git/ test-git2 > > cd test-git2 > > cg-rm file > > git-commit-script -m 'testing' > > ls > > > cg-push > > cd ../test-git > > git-checkout-script > > Ah, okay. I think "push" and "checkout" don't play that well together; > "push" changes the ref, which "checkout" uses to determine what it expects > for the old contents, and then it's confused. > > What you probably actually want is: > > cd ../test-git > git pull ../test-git2 The point is to push and use a post-update hook to do the checkout. So, this won't be possible. > which will correctly identify before and after, and remove any files that > were removed. > > Alternatively, you could do, at point 1: > > cp .git/refs/master .git/refs/deployed > git checkout deployed How to get a post-update hook to do this? I suppose an update script could set this up for the post-update to later use. 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: [RFC] Removing deleted files after checkout
On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote: > On Tue, 23 Aug 2005, Carl Baldwin wrote: > > > 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. > > 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. Maybe I'm doing something wrong. This does not happen for me. I tried a simple test with git v0.99.4... cd mkdir test-git && cd test-git/ echo testing | cg-init echo contents > file git-add-script file git-commit-script -m 'testing' cd .. cg-clone test-git/.git/ test-git2 cd test-git2 cg-rm file git-commit-script -m 'testing' ls cg-push cd ../test-git git-checkout-script ls git-status-script At this point, I want 'file' to be gone. It is, however, still there. That is the situation that my code was meant to handle. Maybe you were thinking of something different? Maybe there is new code since 0.99.4? Now, I think it would be wrong for git-checkout-script to actually remove files unless an option were given to do so. So, the behavior that I observe is correct in my opinion. I'm looking for a way to find out what files should be deleted if that is desired. Thanks, Carl > -Daniel > *This .sig left intentionally blank* > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
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: cg-update/cg-merge refuse to update if state is dirty?
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
Re: Making note, in the repository, of push/pull relationships
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: Making note, in the repository, of push/pull relationships
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
On Tue, Aug 16, 2005 at 12:49:33AM +0200, Johannes Schindelin wrote: > Hi, > > On Mon, 15 Aug 2005, Carl Baldwin wrote: > > > Somewhere in the thread something was mentioned about maintaining > > : pairs in the git repository when pushes > > and pulls are performed. I think the argument was actually against > > keeping this information and ultimately against allowing pushes to a > > branch of a different name. > > I think the loudest voice was mine :-) > > Actually, I was not against *keeping* the information, but against > *pulling* in such strange ways. If "cross-pulling" is allowed, I am all > for keeping track of that. So, just a question. What, exactly, is meant by 'cross-pulling'? > In the meantime, I did not think about the issue at all :-) However, as is > often the case in an open discussion, I think I was wrong after all. There > may be cases you want that, and in the end, nobody forces me to use that > feature. > > Anyway, Junio decided to enhance the fetch mechanism to support the > cross-pulling (and also multi-pulling). > > Ciao, > Dscho > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
Making note, in the repository, of push/pull relationships
(Sorry for the repost. The other one was an accident.) Over the week-end, I was thinking about the thread "Re: How is working on arbitrary remote heads supposed to work in Cogito". I wanted to weigh in an opinion that I've developed on it but thought it deserved a new thread. Somewhere in the thread something was mentioned about maintaining : pairs in the git repository when pushes and pulls are performed. I think the argument was actually against keeping this information and ultimately against allowing pushes to a branch of a different name. I wanted to weigh in with why it would be a good idea to make note of this information. The only thing that would be required of the plumbing is to specify how this information is kept and if a push or pull is performed directly with git then make note of the push/pull relationship. Everything else would be up to the porcelains. So, I envision a simple directed graph where nodes represent the branches (wether local or remote) and the edges represent push or pull relationships between branches. Git already stores the nodes. The edges, in theory, would spring into existence when a push or pull is performed between two branches for the first time. This graph will be extremely useful for manageing flow in a project. It could enable something as simple as a script that would walk the edges and tell which ones have fallen behind. It would also be possible to easily pull up a visual representation of the graph (with graphviz, maybe). This sort of thing might prove to be a valuable orientation tool for the developer or project manager. It could also enable some very powerful project flow management --- in a porcelain of course --- that would manage flow from an engineer's own sand-box through software engineering 'gates' such as integration, quality assurance, product maintenance and the documentation and sign-offs required to pass through each of these gates. It could also be used to aid in documenting and managing the, already existent, linux tree development flow in whatever way suits. This is a big return on investment. Little would be required of the plumbing to maintain these 'edges', just add to them when it performs a push/pull on an edge that hasn't already been recorded. Any changes or deletions could be handled by the user or by some porcelain. I think it is important, though, to specify how this information should be stored to maintain compatibility between porcelains while (hopefully) allowing for some degree of flexibility. I don't yet know where this line should be drawn. 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)?
Over the week-end, I was thinking about the thread "Re: How is working on arbitrary remote heads supposed to work in Cogito". I wanted to weigh in an opinion that I've developed on it but thought it deserved a new thread. Somewhere in the thread something was mentioned about maintaining : pairs in the git repository when pushes and pulls are performed. I think the argument was actually against keeping this information and ultimately against allowing pushes to a branch of a different name. I wanted to weigh in with why it would be a good idea to make note of this information. The only thing that would be required of the plumbing is to specify how this information is kept and if a push or pull is performed directly with git then make note of the push/pull relationship. Everything else would be up to the porcelains. So, I envision a simple directed graph where nodes represent the branches (wether local or remote) and the edges represent push or pull relationships between branches. Git already stores the nodes. The edges, in theory, would spring into existence when a push or pull is performed between two branches for the first time. This graph will be extremely useful for manageing flow in a project. It could enable something as simple as a script that would walk the edges and tell which ones have fallen behind. It would also be possible to easily pull up a visual representation of the graph (with graphviz, maybe). This sort of thing might prove to be a valuable orientation tool for the developer or project manager. It could also enable some very powerful project flow management --- in a porcelain of course --- that would manage flow from an engineer's own sand-box through software engineering 'gates' such as integration, quality assurance, product maintenance and the documentation and sign-offs required to pass through each of these gates. It could also be used to aid in documenting and managing the, already existent, linux tree development flow in whatever way suits. This is a big return on investment. Little would be required of the plumbing to maintain these 'edges', just add to them when it performs a push/pull on an edge that hasn't already been recorded. Any changes or deletions could be handled by the user or by some porcelain. I think it is important, though, to specify how this information should be stored to maintain compatibility between porcelains while (hopefully) allowing for some degree of flexibility. I don't yet know where this line should be drawn. Carl On Sat, Aug 13, 2005 at 12:48:32AM -0700, Junio C Hamano wrote: > Carl Baldwin <[EMAIL PROTECTED]> writes: > > > 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. > > > > Sorry to join the game so late. I've only read this thread now. > > Just in case you have not noticed, the push in 0.99.4 and > onwards does exactly that. Please see git-push-script.txt in > the Documentation/ directory --- oops, there is no such thing. > > Please see git-send-pack.txt instead, and if you feel like it, I > would appreciate a patch to add the missing documentation for > git-push-script ;-). > > What's not supported well yet is the opposite --- downloading > multiple refs and dealing with them. > > Johannes Schindelin calls this "reverse push", and I think that > is really a good name to describe what it does. It takes a > remote repository and possibly multiple refs, downloads the > objects to complete the named remote references, and updates the > local refs only if the remote refs are fast forward children of > the local refs being replaced, just like "push" fast forwards > the remote refs using the local refs. In other words, given > and repository, the following should do the same > thing: > > On repository machine, with GIT_DIR being the repository: > $ git push :... > > On repository machine, with GIT_DIR being the repository: > $ git pull :... > > Johannes posted a script on the list a couple of days ago, which > should work well, except that it was written before the > git-fetch-pack command was updated to natively download from > multiple refs, so it does not know how to fetch multiple refs at > a one go. > > -jc > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard C
Re: Add an empty directory?
On Sat, Aug 13, 2005 at 12:41:45PM -0700, Linus Torvalds wrote: > > > On Sat, 13 Aug 2005, Carl Baldwin wrote: > > > > 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. > > Well, there is an argument for not supporting it, namely that the way > patches work, traditionally a directory that became empty is deleted > (because patches have no way of saying "remove directory" or "create > directory"). > > So a system where the existence of a directory flows from the existence of > the files within the directory will automatically always do the right > thing with patches floating around. I see your point here. However, if git supported it then any particular usage model on top of git could choose to do it either way. If it doesn't then that flexibility is not there. > Which is a big deal for me, since most of the kernel development still > ends up being done with patches. Yes, we merge things with git, but a lot > of the development is about passing patches around for review and > commentary. > > And the thing is, you can always create the directory in your workspace. > Git won't care, and won't know about it, but there's really no downside to > it. > > Linus > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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?
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)?
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
