* Re: [PATCH] Documentation: Transplanting branch with git-rebase --onto
From: Junio C Hamano @ 2006-11-06 22:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Carl Worth
In-Reply-To: <200611061912.46436.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Added example of transplantig feature branch from one development
> branch (for example "next") into the other development branch (for
> example "master").
>
> [jn: with a little help from Junio]
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> What about this?
I agree with Carl that the original example of --onto was not
clear why it is a good thing, so I am inclined to follow his
suggestion and drop the original example and keep your second
one yanked from your try#1 patch when committing, if it is Ok
with you.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-11-06 22:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611062258.08320.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Here is example code for this:
Ok. The issues I raised in the previous round seem to have been
addressed. Maybe you would want not to use nested 'sub' and it
is good to go, I think.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-06 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200611032333.49794.jnareb@gmail.com>
Jakub Narebski wrote:
> 3. Use Character Escape Codes (CEC), using alphabetic and octal
> backslash sequences like those used in C. Probably need to escape
> backslash (quoting character) too. Has the advantage of being widely
> understood in POSIX world. Has the disadvantage of need for escape
> sequence table/hash. Has the advantage that it works for all
> characters - simple octal backslash sequence if they have no special
> escape sequence.
Here is example code for this:
sub esc_path {
my $str = shift;
sub quot {
my $seq = shift;
my %es = (
"\t" => '\t', # tab (HT, TAB)
"\n" => '\n', # newline (NL)
"\r" => '\r', # return (CR)
"\f" => '\f', # form feed (FF)
"\b" => '\b', # backspace (BS)
"\a" => '\a', # alarm (bell) (BEL)
"\e" => '\e', # escape (ESC)
"\013" => '\v', # vertical tab (VT)
);
if (exists $es{seq}) {
return $es{$seq};
}
return sprintf("\\%03o", ord($seq));
}
$str = esc_html($str);
$str =~ s/([[:cntrl:]])/'<span class="cntrl">' . quot($1) . '</span>'/eg;
return $str;
}
--
Jakub Narebski
^ permalink raw reply
* Re: Merge branch to directory of other branch.
From: Alex Riesen @ 2006-11-06 21:49 UTC (permalink / raw)
To: Kirill Shutemov; +Cc: git
In-Reply-To: <1d592d70611061001n6d6f7aa8tbd34a45c5d968eab@mail.gmail.com>
Kirill Shutemov, Mon, Nov 06, 2006 19:01:02 +0100:
> I have one branch with full content and other branch with one
> directory from first branch. How can I merge this branches?
Assuming they are related:
git checkout -b merged full
git pull . one-directory
^ permalink raw reply
* Re: [PATCH/RFC] Documentation: Two more git-rebase --onto examples
From: Junio C Hamano @ 2006-11-06 19:18 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <87zmb4v3vu.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I think Jakub's explanations do a much better job of explaining
> something someone might actually want to do and then showing how to do
> it. So if there's redundancy I'd vote for dropping the old stuff.
I agree with that.
> Meanwhile, while we're talking about git-rebase documentation, the
> recent posts about the:
>
> git rebase --onto <foo> <upstream> <branch>
>
> form take advantage of the fact that this command also changes the
> current branch to <branch>. I think that's quite surprising behavior,
> (though useful in the example that was given). It's perhaps out of
> line with the scope of git-rebase but it should at least be
> documented. I think that will need some specific mention before the
> examples.
Good point.
^ permalink raw reply
* Re: how to show log for only one branch
From: Junio C Hamano @ 2006-11-06 18:16 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <454F1175.9080506@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> ... For example, I want to know what happened in your
> git's "next" branch, I hope to get logs like this:
> Merge branch 'jc/pickaxe' into next
> Merge branch 'master' into next
> Merge branch 'js/modfix' into next
> ...
> some good work
> ...
> Merge branch ....
>
> I just want to *outline* what happened in "next" branch, if I am interested
> in what have been merged from 'jc/pickaxe' I can follow the merge point again
> or use something like "git log --follow-all-parents".
My "next" is a bad example of this, because it is an integration
branch and never gets its own development. It is also a bad
example because I can answer that question with this command
line:
git log --grep='^Merge .* into next$' next
and while it is a perfectly valid answer, I know it would leave
you feeling somewhat cheated.
^ permalink raw reply
* Re: [PATCH/RFC] Documentation: Two more git-rebase --onto examples
From: Carl Worth @ 2006-11-06 18:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200611051122.17623.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
On Sun, 5 Nov 2006 11:22:17 +0100, Jakub Narebski wrote:
> I found original example somewhat artifical, but after thinking on that
> I guess that the need for rebase onto master~1 might happen when the last
> commit in master is for example to be amended or rebased.
It is quite artificial in presentation at least. There's no motivating
explanation of what is being attempted just before-and-after diagrams
along with a command that achieves the result. That presentation makes
it very hard to learn how to usefully use the command from the
description.
> > This looks the same as the original example for --onto; I would
> > either drop it or replace it something of different flavor.
>
> This example is from latest post by Andy Parkins, which asked how to
> do that. But I find your example as being better, because it shows
> even more power of core git history manipulation.
I think Jakub's explanations do a much better job of explaining
something someone might actually want to do and then showing how to do
it. So if there's redundancy I'd vote for dropping the old stuff.
Meanwhile, while we're talking about git-rebase documentation, the
recent posts about the:
git rebase --onto <foo> <upstream> <branch>
form take advantage of the fact that this command also changes the
current branch to <branch>. I think that's quite surprising behavior,
(though useful in the example that was given). It's perhaps out of
line with the scope of git-rebase but it should at least be
documented. I think that will need some specific mention before the
examples.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Documentation: Transplanting branch with git-rebase --onto
From: Jakub Narebski @ 2006-11-06 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200611051122.17623.jnareb@gmail.com>
Added example of transplantig feature branch from one development
branch (for example "next") into the other development branch (for
example "master").
[jn: with a little help from Junio]
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
What about this?
The second example I think has place in tutorial or GitTips on GitWiki
Documentation/git-rebase.txt | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 10f2924..9e822c5 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -65,6 +65,40 @@ would be:
D---E---F---G master
------------
+
+Here is how you would transplant a topic branch based on one
+branch to another, to pretend that you forked the topic branch
+from the latter branch, using `rebase --onto`.
+
+First let's assume your 'topic' is based on branch 'next'.
+For example feature developed in 'topic' depends on some
+functionality which is found in 'next'.
+
+------------
+ o---o---o---o---o master
+ \
+ o---o---o---o---o next
+ \
+ o---o---o topic
+------------
+
+We would want to make 'topic' forked from branch 'master',
+for example because the functionality 'topic' branch depend on
+got merged into more stable 'master' branch, like this:
+
+------------
+ o---o---o---o---o master
+ | \
+ | o'--o'--o' topic
+ \
+ o---o---o---o---o next
+------------
+
+We can get this using the following command:
+
+ git-rebase --onto master next topic
+
+
In case of conflict, git-rebase will stop at the first problematic commit
and leave conflict markers in the tree. You can use git diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
--
1.4.3.4
^ permalink raw reply related
* Merge branch to directory of other branch.
From: Kirill Shutemov @ 2006-11-06 18:01 UTC (permalink / raw)
To: git
I have one branch with full content and other branch with one
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Linus Torvalds @ 2006-11-06 17:48 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611060734490.25218@g5.osdl.org>
On Mon, 6 Nov 2006, Linus Torvalds wrote:
>
> Besides, doing an empty commit like that ("I fast forwarded") literally
> doesn't add any true history information. It literally views history not
> as history of the _project_, but as the history of just one of the
> repositories. And that's wrong.
>
> So just get used to it. You MUST NOT do what you want to do. It's stupid.
Btw, absolutely the _only_ reason people seem to want to do this is
because they want to "pee in the snow" and put their mark on things. They
seem to want to show "_I_ did this", even if the "doing" was a total
no-op and they didn't actually generate any real value.
That's absolutely the last thing you want to encourage, especially when
the end result is a history that is totally unreadable and contains more
"junk" than actual real work.
I'll be the first to say that "merging code" is often as important as
actually writing the code in the first place, and that it is important to
show who actually did real work to make a patch appear in a project.
In the kernel, for example, we have "sign-off" lines to show what route a
patch took before it was accepted, and it's very instructive to see (for
example) how man patches give credit to somebody like Andrew Morton for
passing it on versus actually writing the code himself (he has a lot of
authorship credit too, but it's absolutely _dwarfed_ by his importance as
a maintainer - and if you were to ask any random kernel developer why
Andrew is so important, I can pretty much guarantee that his importance is
very much about those "sign-offs", and not about the patches he authors).
But at the same time, when it comes to merging, because it actually
clutters up history a lot, we actively try to _avoid_ it. Many subsystem
maintainers purposefully re-generate a linear history, rebased on top of
my current kernel, exactly because it makes the history less "branchy",
and because that makes things easier to see.
So we have actually done work to _encourage_ fast-forwarding over "merge
with a commit", because the fast-forwarding ends up generating a much more
readable and understandable history. Generating a _fake_ "merge commit"
would be absolutely and utterly horrible. It gives fake credit for work
that wasn't real work, and it makes history uglier and harder to read.
So it's a real NEGATIVE thing to have, and you should run away from it as
fast as humanly possible.
Now, the kernel actually ends up being fairly branchy anyway, but that's
simply because we actually have a lot of real parallel development (I bet
more than almost any other project out there - we simply have more commits
done by more people than most projects). I tend to do multiple merges a
day, so even though people linearize their history individually, you end
up seeing a fair amount of merges. But we'd have a lot _more_ of them if
people didn't try to keep history clean.
Btw, in the absense of a merge, you can still tell who committed
something, exactly because git keeps track of "committer" information in
addition to "authorship" information. I don't understand why other
distributed environments don't seem to do this - because separating out
who committed something (and when) from who authored it (and when) is
actually really really important.
And that's not just because we use patches and other SCM's than just git
to track things (so authorship and committing really are totally separate
issues), but because even if the author and committer is the same person,
it's very instructive to realize that it might have been moved around in
history, so it might actually have been cherry-picked later, and the
committer date differs from the author date even if the actual author and
committer are the same person (but you might also have had somebody _else_
re-linearize or otherwise cherry-pick the history: again, it's important
to show the committer _separately_ both as a person and as a date).
And because there is a committer field, if you actually want to linearize
or log things by who _committed_ stuff, you can. Just do
git log --committer=torvalds
on the kernel, and you can see the log as it pertains for what _I_
committed, for example. You can even show it graphically, although it
won't be a connected graph any more, so it will tend to be very ugly
(but you'll see the "linear stretches" when somebody did some work). Just
do "gitk --committer=myname" to see in your own project.
^ permalink raw reply
* Re: [PATCH] git-pickaxe -C -C -C
From: Junio C Hamano @ 2006-11-06 17:25 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200611061646.kA6GkHgi009592@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Three -C options makes the command to look for copied lines from _any_
>> existing file in the parent commit, not just changed files.
>
> IMHO, this is horrible UI.
>
> -C is one thing
> -C -C is another
> -C -C -C is still another?
I think of it as "-v" vs "-v -v" vs "-v -v -v" some programs use
to give you increasing levels of verbosity.
Triple-C version is a kind of joke and not to be integrated
(although it seems to work as advertised, it is inpractically
slow), so it really is between -C vs -C -C, but certainly I am
open to better ways of specifying the current -C/-C -C options.
^ permalink raw reply
* Re: [PATCH] git-pickaxe -C -C -C
From: Horst H. von Brand @ 2006-11-06 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz75djt1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Three -C options makes the command to look for copied lines from _any_
> existing file in the parent commit, not just changed files.
IMHO, this is horrible UI.
-C is one thing
-C -C is another
-C -C -C is still another?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Martin Langhoff @ 2006-11-06 16:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Liu Yubao, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611060734490.25218@g5.osdl.org>
On 11/6/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 6 Nov 2006, Liu Yubao wrote:
> > Then, what bad *logical* problem will happen if a merging that is really a
> > fast forwarding creates a new commit?
> You MUST NOT do that.
>
> If a fast-forward were to do a "merge commit", you'd never get into the
> situation where two people merging each other would really ever get a
> stable result. They'd just keep doing merge commits on top of each other.
Indeed. I used Arch for quite a while and if you were merging between
2 or more repos it would never reach a stable point even if the code
didn't change at all.
If a group of 3 developers (with one repor per developer) was
developing at a slow pace (say, a daily commit each, plus a couple of
pull/updates per day) the garbage-commit to content-commit ratio was
awful. If on a given day noone had made a single commit, we'd still
have a whole set of useless updates merged and committed.
> Besides, doing an empty commit like that ("I fast forwarded") literally
> doesn't add any true history information.
And as the number of developers and repos grows in a distributed
scenarios, fast-forwards increasingly outnumber real commits. The
usefulness of your logs sinks to the sewers.
cheers,
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Linus Torvalds @ 2006-11-06 15:48 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git
In-Reply-To: <454F31D7.1030202@gmail.com>
On Mon, 6 Nov 2006, Liu Yubao wrote:
>
> Then, what bad *logical* problem will happen if a merging that is really a
> fast forwarding creates a new commit?
You MUST NOT do that.
If a fast-forward were to do a "merge commit", you'd never get into the
situation where two people merging each other would really ever get a
stable result. They'd just keep doing merge commits on top of each other.
Git tracks history, not "your view of history". Trying to track "your
view" is fundamentally wrong, because "your wiew" automatically means that
the project history would not be distributed any more - it would be
centralized around what _you_ think happened. That is not a sensible thing
to have in a distributed system.
For example, the way to break the "infinite merges" problem above is to
say that _you_ would be special, and you would do a "fast-forward commit",
and the other side would always just fast-forward without a commit. But
that is very fundamentally against the whole point of being distributed.
Now you're special.
In fact, even for "you", it would be horrible - because you personally
might have 5 different repositories on five different machines. You'd have
to select _which_ machine you want to track. That's simply insane. It's a
totally broken model. (You can even get the same situation with just _one_
repository, by just having five different branches - you have to decide
which one is the "main" branch).
Besides, doing an empty commit like that ("I fast forwarded") literally
doesn't add any true history information. It literally views history not
as history of the _project_, but as the history of just one of the
repositories. And that's wrong.
So just get used to it. You MUST NOT do what you want to do. It's stupid.
If you want to track the history of one particular local branch, use the
"reflog" thing. It allows you to see what one of your local branches
contained at any particular time.
See
[core]
logAllRefUpdates = true
documentation in "man git-update-refs" (and maybe somebody can write more
about it?)
^ permalink raw reply
* Re: how to show log for only one branch
From: Jakub Narebski @ 2006-11-06 15:25 UTC (permalink / raw)
To: git
In-Reply-To: <454EAEDB.8020909@gmail.com>
Perhaps what you want is git log --committer=<owner of repo>?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git PATH reordering
From: Andy Whitcroft @ 2006-11-06 13:58 UTC (permalink / raw)
To: Janos Farkas; +Cc: git
In-Reply-To: <priv$efbe06146839$619d340665@200611.gmail.com>
Janos Farkas wrote:
> Hi!
>
> I'm facing an issue which seems to originate about a year ago, so I'm a
> bit late :)
>
> Apparently, most git commands seem to tweak their PATH to make sure the
> corresponding version of a subcommand gets ran in the case there are
> multiple ones in there.
>
> The thing is, since this "ensuring" is done by prepend_to_path(), which
> can then change all exec() afterwards. Usually, that's not a problem,
> but that made git run an unexpectedly different ssh command for remote
> access. When I discovered what the problem is, I easily fixed it by
> setting GIT_SSH to the explicit path, and I can live with that, but it's
> a bit confusing.
>
> I don't want to start a neverending thread, so if my bikeshed doesn't
> interest you, I'll give up :) But the way it's done now seems to be for
> the case which should be very rare.
>
> As I see, all this PATH manipulation logic was meant to solve the case
> when the desired "git" version is not in the path or some mismatching
> components of it is. Including the case when you want to point some
> higher level tool to one specific version of "git" to be used,
> irrespective of PATH. Is this the right way to do it? Is it
> really required at all?
Well its pretty important if you run /usr/local/foo/git clone its
running git-clone from the version you think it is going to.
>
> Apart from getting rid of this (possibly useful?) munging, I could see
> about two ways to change the behavior to less surprising:
>
> - Don't make PATH munging if "our" path is in the PATH already.
> - Save the PATH before munging, and restore before any non-git command
> is run. This is a bit complex, as multiple languages are used,
> including sh..
>
> Both could make sense, but I don't think either is the correct way.
It sounds a lot like we want to be running the equivalent of `dirname
$0`/git-cmd over git-cmd in all cases to ensure we get the right ones.
Perhaps we could export that as GIT_BIN inside the tools.
Something like this might work for shell:
export GIT_BIN=${GIT_BIN:-`dirname $0`}
$GIT_BIN/git-rev-list ...
Thoughts?
>
> What bit me, if someone cares about the details, is that on my system,
> everything is in the correct path, even git*. There is however a private
> ~/bin at the front of the PATH containing some preferred/fixed versions
> of some system tools. When git (living as a normal citizen in /usr/bin)
> does its PATH munging, it puts /usr/bin in the front of the path,
> skipping this well built house of cards. As I said, I can live with
> that, since only ssh is one that I can designate as "important", and
> that one can be set separately with GIT_SSH, but still..
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Andreas Ericsson @ 2006-11-06 13:43 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git
In-Reply-To: <454F31D7.1030202@gmail.com>
Liu Yubao wrote:
> Thanks to Junio for his patient explanation about branches in git, I
> find there is a subtle difference between GIT and regular VCS that can
> be easily
> neglected by newbies.
>
> I realize that git is a *content tracker*, it only creates commit object
> when the corresponding tree is really modified, git records content merging
> but not usual merging operation, that's why git is called a content
> tracker.
> This explains why a merging that is really a fast forwarding doesn't create
> any new commit.
>
> This feature is different from many regular VCS like CVS and Subversion and
> confuses newbies that come from them: mainline doesn't make sense too much,
> 'git log' shows many logs from other branches. In git, a branch is almost a
> tag, you can't get the *track* of a branch(It's a pity reflog is only for
> local purpose). I am used to one-trunk-and-more-side-branches way, every
> branches are isolated clearly, git makes me very confused at the beginning.
>
>
> Then, what bad *logical* problem will happen if a merging that is really
> a fast forwarding creates a new commit?
>
If "fake" commits (i.e., commits that doesn't change any content) are
introduced for each merge, it will change the ancestry graph and the
resulting tree(s) won't be mergable with the tree it merged with,
because each such "back-merge" would result in
* the "fake" commit becoming part of history
* a new "fake" commit being introduced
Consider what happens when Alice pulls in Bob's changes. The merge-base
of Bob's tip is where Alice HEAD points to, so it results in a
fast-forward, like below.
a---b---c---d <--- Alice
\
e---f---g <--- Bob
If, we would have created a fake commit instead, Alice would get a graph
that looks like so:
a---b---c---d-----------h <--- Alice
\ /
e---f---g <--- Bob
Now, we would have two trees that are identical, because the merge can't
cause conflicts, but Alice and Bob will have reached it in two different
ways. When Bob decides he wants to go get the changes Alice has done,
his tree will look something like this:
a---b---c---d-----------h <--- Alice
\ / \
e---f---g---i <--- Bob
He finds it odd that he's got two commits that, when checked out, lead
to the exact same tree, so he asks Alice to get his tree and see what's
going on. Alice will then end up with this:
a---b---c---d-----------h---j <--- Alice
\ / \ /
e---f---g---i <--- Bob
Now there's four commits that all point to identical trees, but the
ancestry graphs differ between all developers. In the case above,
there's only two people working at the same project. Imagine the amount
of empty commits you'd get in a larger project, like the Linux kernel.
Fast-forward is a Good Thing and the only sensible thing to do in a
system designed to be fully distributed (i.e., where there isn't
necessarily any middle point with which everybody syncs), while scaling
beyond ten developers that merge frequently between each other.
> If we throw away all compatibility, efficiency, memory and disk consumption
> problems,
> (1) we can get the track of a branch without reflog because HEAD^1 is
> always the tip of target branch(or working branch usually) before merging.
>
> (2) with the track, branch mechanism in git is possibly easier to
> understand,
> especially for newbies from CVS or Subversion, I really like git's light
> weight, simple but powerful design and great efficiency, but I am really
> surprised that 'git log' shows logs from other branches and a side
> branch can become part of main line suddenly.
>
> A revision graph represents fast forwarding style merging like this:
>
> (fast forwarding)
> ---- a ............ * ------> master
> \ /
> b----------c -----> test (three commits with three trees)
>
> can be changed to:
>
> ---- a (tree_1) ----------- d (tree_3) ------> master
> \ /
> b (tree_2) ------- c (tree_3) ----> test
> (four commits with three trees, it's normal as more than one way can
> reach Rome :-)
>
That's where our views differ. In my eyes, "d" and "c" are exactly
identical, and I'd be very surprised if the scm tried to tell me that
they aren't, by not giving them the same revid.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit
From: Rocco Rutte @ 2006-11-06 13:39 UTC (permalink / raw)
To: git
In-Reply-To: <454F31D7.1030202@gmail.com>
Hi,
* Liu Yubao [06-11-06 21:00:07 +0800] wrote:
>Then, what bad *logical* problem will happen if a merging that is really a fast forwarding creates a new commit?
I don't know what you expect by "logical" nor if I get you right, but if
fast-forward merge a branch to another one, both branches now have
exactly the same hash. If you create a commit object for a fast-forward
merge, both tip hashes not identical anymore... which is bad.
The identical hash important so that you really know they're identical
and for future reference like ancestry.
bye, Rocco
--
^ permalink raw reply
* git PATH reordering
From: Janos Farkas @ 2006-11-06 13:33 UTC (permalink / raw)
To: git
Hi!
I'm facing an issue which seems to originate about a year ago, so I'm a
bit late :)
Apparently, most git commands seem to tweak their PATH to make sure the
corresponding version of a subcommand gets ran in the case there are
multiple ones in there.
The thing is, since this "ensuring" is done by prepend_to_path(), which
can then change all exec() afterwards. Usually, that's not a problem,
but that made git run an unexpectedly different ssh command for remote
access. When I discovered what the problem is, I easily fixed it by
setting GIT_SSH to the explicit path, and I can live with that, but it's
a bit confusing.
I don't want to start a neverending thread, so if my bikeshed doesn't
interest you, I'll give up :) But the way it's done now seems to be for
the case which should be very rare.
As I see, all this PATH manipulation logic was meant to solve the case
when the desired "git" version is not in the path or some mismatching
components of it is. Including the case when you want to point some
higher level tool to one specific version of "git" to be used,
irrespective of PATH. Is this the right way to do it? Is it
really required at all?
Apart from getting rid of this (possibly useful?) munging, I could see
about two ways to change the behavior to less surprising:
- Don't make PATH munging if "our" path is in the PATH already.
- Save the PATH before munging, and restore before any non-git command
is run. This is a bit complex, as multiple languages are used,
including sh..
Both could make sense, but I don't think either is the correct way.
What bit me, if someone cares about the details, is that on my system,
everything is in the correct path, even git*. There is however a private
~/bin at the front of the PATH containing some preferred/fixed versions
of some system tools. When git (living as a normal citizen in /usr/bin)
does its PATH munging, it puts /usr/bin in the front of the path,
skipping this well built house of cards. As I said, I can live with
that, since only ssh is one that I can designate as "important", and
that one can be set separately with GIT_SSH, but still..
^ permalink raw reply
* If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Liu Yubao @ 2006-11-06 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk629f6is.fsf@assigned-by-dhcp.cox.net>
Thanks to Junio for his patient explanation about branches in git, I find
there is a subtle difference between GIT and regular VCS that can be easily
neglected by newbies.
I realize that git is a *content tracker*, it only creates commit object
when the corresponding tree is really modified, git records content merging
but not usual merging operation, that's why git is called a content tracker.
This explains why a merging that is really a fast forwarding doesn't create
any new commit.
This feature is different from many regular VCS like CVS and Subversion and
confuses newbies that come from them: mainline doesn't make sense too much,
'git log' shows many logs from other branches. In git, a branch is almost a
tag, you can't get the *track* of a branch(It's a pity reflog is only for
local purpose). I am used to one-trunk-and-more-side-branches way, every
branches are isolated clearly, git makes me very confused at the beginning.
Then, what bad *logical* problem will happen if a merging that is really a
fast forwarding creates a new commit?
If we throw away all compatibility, efficiency, memory and disk consumption
problems,
(1) we can get the track of a branch without reflog because HEAD^1 is
always the tip of target branch(or working branch usually) before merging.
(2) with the track, branch mechanism in git is possibly easier to understand,
especially for newbies from CVS or Subversion, I really like git's light
weight, simple but powerful design and great efficiency, but I am really
surprised that 'git log' shows logs from other branches and a side branch can
become part of main line suddenly.
A revision graph represents fast forwarding style merging like this:
(fast forwarding)
---- a ............ * ------> master
\ /
b----------c -----> test (three commits with three trees)
can be changed to:
---- a (tree_1) ----------- d (tree_3) ------> master
\ /
b (tree_2) ------- c (tree_3) ----> test
(four commits with three trees, it's normal as more than one way can reach
Rome :-)
I don't think I am smarter than any people in this mailing list, in fact
I am confused very much by GIT's branches at the beginning. There must
be many problems I haven't realized, I am very curious about them, any
^ permalink raw reply
* Re: git bug? + question
From: Andy Whitcroft @ 2006-11-06 12:32 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Shawn Pearce, Sean, Junio C Hamano, Miles Bader, git,
Karl Hasselström
In-Reply-To: <200611061200.08972.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Monday 06 November 2006 10:53, Andy Whitcroft wrote:
>> Josef Weidendorfer wrote:
>>> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
>>>> After reading your reply you are probably correct. I can see there
>>>> may be workflows that want every remote branch also created as a
>>>> local branch.
>>>>
>>>> I could certainly live with a command line option to clone, e.g.:
>>>>
>>>> git clone --only vmdvt,vmtip user@host:/path...
>>> Still missing here: What branch should be checked out after
>>> cloning?
>> Does any need to be checked out?
>
> We should not change existing behavior. IMHO, checking out a branch is
> mostly the right thing to do. Of course, you often want to specify which one.
> The current requirement for a master branch in the origin repository
> is really bad, as it obviously requires ugly workarounds in some cases
> (and totally confuse newbies in such use cases).
We are not changing existing behaviour, if we do not check anything out
only when specifying '--only'.
>
>> Or perhap I should put it another way,
>> when we make a virgin repository we default to master checked out but
>> its not joined to the DAG.
>
> I do not understand this. By creating a local branch, the commit DAG
> is never changed.
In a virgin repository there is no DAG to speak of and master doesn't
really point anywhere until the first commit. I was proposing that when
--only is specified, we just leave things as they are. The master half
pointing into the zero element DAG we have in an entirely empty repo.
The new unconnected DAG or DAG's we have downloaded in the clone will be
attached to their respective branch names.
^ permalink raw reply
* Re: git bug? + question
From: Josef Weidendorfer @ 2006-11-06 11:05 UTC (permalink / raw)
To: Shawn Pearce
Cc: Sean, Junio C Hamano, Miles Bader, git, Karl Hasselström
In-Reply-To: <20061104190512.GA2517@spearce.org>
On Saturday 04 November 2006 20:05, Shawn Pearce wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> >
> > git checkout origin/vmdvt
> >
> > should create a new local branch refs/heads/vmdvt which forks
> > from remotes/origin/vmdvt (and abort with
> > error if refs/heads/vmdvt already exists without being the local
> > development branch for remotes/origin/vmdvt)
>
> Yes, that would work for our workflow. I won't try to speak about
> anyone else's.
>
> I'd also say that if the local branch (refs/heads/vmdvt) exists and
> if `git pull . origin/vmdvt` is going to be a fast-forward that the
> fast-forward should happen during the checkout. That way after the
> checkout is complete you really do have what is in origin/vmdvt,
> but are sitting on a local branch.
Hmmm... But you are changing the tip of a local development branch,
which is probably not always the thing we want.
Thinking about it, we should always error out if a proposed branch
name for a read-only branch already exists.
Josef
^ permalink raw reply
* Re: git bug? + question
From: Josef Weidendorfer @ 2006-11-06 11:00 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Shawn Pearce, Sean, Junio C Hamano, Miles Bader, git,
Karl Hasselström
In-Reply-To: <454F0636.1060406@shadowen.org>
On Monday 06 November 2006 10:53, Andy Whitcroft wrote:
> Josef Weidendorfer wrote:
> > On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
> >> After reading your reply you are probably correct. I can see there
> >> may be workflows that want every remote branch also created as a
> >> local branch.
> >>
> >> I could certainly live with a command line option to clone, e.g.:
> >>
> >> git clone --only vmdvt,vmtip user@host:/path...
> >
> > Still missing here: What branch should be checked out after
> > cloning?
>
> Does any need to be checked out?
We should not change existing behavior. IMHO, checking out a branch is
mostly the right thing to do. Of course, you often want to specify which one.
The current requirement for a master branch in the origin repository
is really bad, as it obviously requires ugly workarounds in some cases
(and totally confuse newbies in such use cases).
> Or perhap I should put it another way,
> when we make a virgin repository we default to master checked out but
> its not joined to the DAG.
I do not understand this. By creating a local branch, the commit DAG
is never changed.
^ permalink raw reply
* Re: how to show log for only one branch
From: Liu Yubao @ 2006-11-06 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk629f6is.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Liu Yubao <yubao.liu@gmail.com> writes:
>
Snip many great detailed description, thank you very much, I have
a question about the way git treats fast forwarding but that will
be another topic.
> What's mainline is _not_ important, and which parent is first is
> even less so. It solely depends on what you are looking for
> which branch matters more. Putting too much weight on the
> difference between HEAD^1 vs HEAD^2 statically does not make any
> sense.
>
> Reflecting this view of history, git log and other history
> traversal commands treat merge parents more or less equally, and
> _how_ you ask your question affects what branches are primarily
> followed. For example, if somebody is interested in your device
> driver work, this command:
>
> git log -- drivers/liu-s-device/
>
> would follow your side branch. On the other hand,
>
> git log -- fs/
>
> would follow Linus's development track while you were forked, if
> you did not do any fs/ work while on that side branch and
> Linus's development track had works in that area, _despite_ the
> merge you gave Linus has your development track as its first
> parent.
>
This is perfect and enough for two branches that work on different
files, but if two branches modify same files, "git log" can't separate
commits clearly. For example, I want to know what happened in your
git's "next" branch, I hope to get logs like this:
Merge branch 'jc/pickaxe' into next
Merge branch 'master' into next
Merge branch 'js/modfix' into next
...
some good work
...
Merge branch ....
I just want to *outline* what happened in "next" branch, if I am interested
in what have been merged from 'jc/pickaxe' I can follow the merge point again
or use something like "git log --follow-all-parents".
Instead, "git log" interlaces logs from many branches, I find it's a little
confused: why does "git log" of current branch contain many logs from other
branches? (This is not a real question, I know the reason)
I indeed understand that HEAD^1 is not always the commit that my work
bases on before a merge (thanks for your detailed description again:-),
it doesn't make sense to show HEAD~1, HEAD~2, HEAD~3 and so on, that's
to say 'git log' will never meet my requirement.
Maybe reflog is what I need, I want to know which commits "next" have pointed
to, but reflog is only for local purpose, it's not downloaded by 'git clone'
^ permalink raw reply
* [PATCH] merge-recursive implicitely depends on trust_executable_bit
From: Alex Riesen @ 2006-11-06 10:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Read the configuration in to get core.filemode value for this
particular repository.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
[-- Attachment #2: 0001-merge-recursive-implicitely-depends-on-trust_executable_bit-core.filemode.txt --]
[-- Type: text/plain, Size: 806 bytes --]
From 193ac65259b5de19fae1a1bd5d4adb55988086f6 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Mon, 6 Nov 2006 09:24:17 +0100
Subject: [PATCH] merge-recursive implicitely depends on trust_executable_bit (core.filemode).
Read the configuration in to get its value for this particular repository
---
merge-recursive.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 2ba43ae..c81048d 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1308,6 +1308,7 @@ int main(int argc, char *argv[])
const char *branch1, *branch2;
struct commit *result, *h1, *h2;
+ git_config(git_default_config); /* core.filemode */
original_index_file = getenv("GIT_INDEX_FILE");
if (!original_index_file)
--
1.4.3.3.gb2828
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox