* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-11-29 0:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061128131139.GA10874@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Just for fun, I took a look at what we might see by ordering commits by
> their "amount of blamedness". That is, the count of lines introduced by
> a commit which were not later superseded. The script I used is below:
>
> #!/bin/sh
>
> start=$1; shift
> end=$1; shift
>
> start_sha1=`git-rev-parse $start^{}`
> git-rev-list --parents $start..$end >revs
> echo $start_sha1 >>revs
> for i in `git-diff --raw -r $start $end | cut -f2`; do
> echo blaming $i... >&2
> git-blame -l -S revs $i | cut -d' ' -f1
> done |
> grep -v $start_sha1 |
> sort | uniq -c | sort -rn |
> while read count hash; do
> echo "$count `git-rev-list --max-count=1 --pretty=oneline $hash`"
> done
>
> The top 15 for v1.4.3 to v1.4.4 are:
>
> 1604 6973dcaee76ef7b7bfcabd2f26e76205aae07858 Libify diff-files.
Something is SERIOUSLY wrong.
That commit is not even between v1.4.3 and v1.4.4.
^ permalink raw reply
* Re: git and bzr
From: Nicholas Allen @ 2006-11-28 22:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0611281432300.4244@woody.osdl.org>
>
> So the tools are certainly there. "git status" just isn't necessarily the
> best one (or the best that it could be, for that matter)..
I guess I hit a limitation in the output of status as opposed to a
limitation in what git can do ;-)
Nick
^ permalink raw reply
* Re: git and bzr
From: Martin Langhoff @ 2006-11-28 22:47 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Git Mailing List, bazaar-ng@lists.canonical.com
In-Reply-To: <456CB9D3.4060900@onlinehome.de>
On 11/29/06, Nicholas Allen <nick.allen@onlinehome.de> wrote:
> > ps: hope you don't mind I re-added the CC to git@vger in my reply
>
> Of course not - I also added bzr mailing list back on this discussion too...
Cool
> For the kind of development we do this is not really a big deal though
> as all developers can agree on using one RCS. But if you mix git and svn
> in this way then the changes can only go one way (from svn to git) can't
> they as svn is not so intelligent so this somewhat limits its usefulness
> doesn't it?
Well, if you look in the git toolset, you'll find things like git-svn
which is geared to make it almost transparent to use git to work on a
project where the upstream is using svn and push patches into SVN (if
you have write access, naturally). And git-cvsexportcommit which is a
lot less useful but helps me push series of patches from git into cvs
easily and with the certaintly that I am not messing up the content.
> I know bzr it has some beta level plugin support for SVN foreign
> branches (git, mercurial and svk ones too I think) and I believe this
> works in both directions. So you can commit to bzr, push that to an svn
> repository and also pull changes from svn. Merge branches in bzr and
> commit back to svn with log messages and history intact. So bzr still
> allows the use of multiple RCS systems...
Sounds roughly like git-svn ;-)
converge, ye DSCMs
^ permalink raw reply
* Re: git and bzr
From: Nicholas Allen @ 2006-11-28 22:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0611281413310.4244@woody.osdl.org>
>
> The other useful tools to be used are "git log --merge" (explained in a
> separate mail) and for people like me who like the git index and grok it
> fully, doing a
>
> git ls-files --unmerged --stage
>
> is probably what I'd do (but I have to admit, that is _not_ a very
> user-friendly interface - you need to not only have understood the index
> file, you actually need to understand it on a very deep level).
>
> "git status" is really used to be just a stupid around "git ls-files"
> (it's now largely a built-in), but it was really _so_ stupid that it
> doesn't really try to explain what it does - it's more like a simplified
> version of ls-files with some of the information pruned away, and other
> parts in a slightly more palatable format ;)
>
> So improving "git status" might mean that some people could avoid having
> to learn about the index file details ;)
That sounds good. Better output on status would be nice ;-)
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-28 22:41 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0611281413310.4244@woody.osdl.org>
On Tue, 28 Nov 2006, Linus Torvalds wrote:
> On Tue, 28 Nov 2006, Nicholas Allen wrote:
> >
> > All useful conflict status is lost isn't it?
>
> No, it's actually there, but "git status" doesn't really explain it to
> you.
Side note, to clarify: in the _simple_ cases it's all actually there.
I can well imagine that in more complex cases, involving multiple
different files, you may well want to re-do the merge and let the merge
tell you why it refused to merge something.
So the index, for example, contains just a "final end result" of what the
merge gave up on, and while for a simple rename conflict like your example
you could certainly see that directly from the index state (and thus we
could, for example, have a "git status" that talks about it being a
filename conflict), if you have a criss-cross rename, the index itself
doesn't really tell you _why_, and it could look superficially like a data
conflict.
In such a case, you'd really have to either go back to the merge itself to
see what happened, or you'd use the "git log" thing and just work it out
from there (ie you can ask "git log" to tell you about any renames as they
happened etc).
I don't think I've actually hit a complex enough merge to need this yet,
but the graphical tools should help too, ie "gitk --merge" should give you
everything that "git log --merge" gives you (ie just the commits that
aren't common, and simplified to just the ones that matter for the
unmerged filenames in the end result). I can well imagine that being
useful too.
So the tools are certainly there. "git status" just isn't necessarily the
best one (or the best that it could be, for that matter)..
^ permalink raw reply
* Re: git and bzr
From: Nicholas Allen @ 2006-11-28 22:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List, bazaar-ng@lists.canonical.com
In-Reply-To: <46a038f90611281414y165ed376r80e3dbc3c7888985@mail.gmail.com>
Martin Langhoff wrote:
> On 11/29/06, Nicholas Allen <nick.allen@onlinehome.de> wrote:
>> yes I can see if you just use plain patches. In bzr though there are
>> bundles that store extra data along with the patch and if you use this
>> instead of a simple patch this will never be a problem as bzr can then
>> notice the same bundle being merged into 2 branches.
>
> Well, there you start depending on everyone using bzr and providing
> metadata-added patches. Git is really good at dealing with scenarios
> where not everyone is using Git.. so the
> content-is-kind-and-metadata-be-damned pays off handsomely.
>
> And the "scenarios where not everyone is using Git" are everytime that
> we are tracking a project that uses a different SCM. For me, the
> "killer-app" of git is that, as it does not rely on magic metadata, it
> is perfectly useful on projects that I track that use CVS or SVN.
>
> I submit or commit patches upstream and git spots the commits being
> echoed back in just right because it does not rely on the metadata.
> Only on the content.
>
> cheers,
>
>
> martin
> ps: hope you don't mind I re-added the CC to git@vger in my reply
Of course not - I also added bzr mailing list back on this discussion too...
I have to agree that's pretty cool!
For the kind of development we do this is not really a big deal though
as all developers can agree on using one RCS. But if you mix git and svn
in this way then the changes can only go one way (from svn to git) can't
they as svn is not so intelligent so this somewhat limits its usefulness
doesn't it?
I know bzr it has some beta level plugin support for SVN foreign
branches (git, mercurial and svk ones too I think) and I believe this
works in both directions. So you can commit to bzr, push that to an svn
repository and also pull changes from svn. Merge branches in bzr and
commit back to svn with log messages and history intact. So bzr still
allows the use of multiple RCS systems...
^ permalink raw reply
* Re: git and bzr
From: Nicholas Allen @ 2006-11-28 22:34 UTC (permalink / raw)
To: bazaar-ng, Git Mailing List
In-Reply-To: <20061128214531.GA24299@jameswestby.net>
Thanks for the informative response. It helped but I'm still slightly
confused by git - I think I need to play around with it a bit more to
understand and get more familiar with the concepts...
Purely from an initial usage point of view though, for me at least, the
bzr output needed no explanation which I think is indicative of a good
user interface whereas the git was not so clear or obvious - there must
be room for improvement in git's user friendliness here surely. But that
might just be because I am clueless when it comes to the way git works
and the concepts it uses ;-)
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-28 22:25 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <456CB197.2030201@onlinehome.de>
On Tue, 28 Nov 2006, Nicholas Allen wrote:
>
> Also what happens if I loose the messages because they scrolled off
> screen or the power goes down, I need to reboot for some reason, or I
> don't have time and want to shutdown my computer restart another day and
> resolve the conflicts then?
I'd suggest just re-doing the merge. Something like
git reset --hard
git merge -m "dummy message" MERGE_HEAD
will do it for you (that's the new "nicer syntax" for doing a merge, in
real life I'd personally just have done a re-pull or somehing)
> All useful conflict status is lost isn't it?
No, it's actually there, but "git status" doesn't really explain it to
you.
The go-to command tends to be "git diff", which after a merge will not
show anything that already merged correctly (because it will have been
updated in the git index _and_ updated in the working tree, so there will
be no diff from stuff that auto-merged). So any output at all after a
failed merge from "git diff" generally tells you exactly what failed.
But since 99%+ of all merge conflicts are data-conflicts, I suspect the
output is mostly geared towards that.
The other useful tools to be used are "git log --merge" (explained in a
separate mail) and for people like me who like the git index and grok it
fully, doing a
git ls-files --unmerged --stage
is probably what I'd do (but I have to admit, that is _not_ a very
user-friendly interface - you need to not only have understood the index
file, you actually need to understand it on a very deep level).
"git status" is really used to be just a stupid around "git ls-files"
(it's now largely a built-in), but it was really _so_ stupid that it
doesn't really try to explain what it does - it's more like a simplified
version of ls-files with some of the information pruned away, and other
parts in a slightly more palatable format ;)
So improving "git status" might mean that some people could avoid having
to learn about the index file details ;)
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Eric Wong @ 2006-11-28 22:24 UTC (permalink / raw)
To: git
In-Reply-To: <20061128220605.GA1253@localdomain>
Eric Wong <normalperson@yhbt.net> wrote:
> finish_report does seem to return a useful value indicating success
> or failure, so we'll just set a flag when close_edit is called
> (it is not called on failures, nor is abort_edit) and check
> the flag before proceeding.
Also, this only affects the delta fetcher. When using the non-delta
fetch: the SVN libraries will just segfault :)
--
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-28 22:22 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <Pine.LNX.4.64.0611281355480.4244@woody.osdl.org>
Linus Torvalds wrote:
> [ For the non-git users, "git log --merge" is just shorthand for a much
> more complicated git revision parsing expression which boils down to:
> "show all commits as they pertain to any remaining unmerged pathnames,
> and only within the symmetrical set difference between the two branches
> you merged". You could write it out as
>
> git log ORIG_HEAD...MERGE_HEAD -- $(git ls-files --unmerged)
>
> but that "git log --merge" is a much simpler shorthand for that thing.
>
> It's not that merge conflicts are necessarily common, but when they do
> happen, that's where you _really_ want the SCM to support you in
> figuring out what happened ]
It would be nice if this was documented in git-log(1), and not only
_partially_ in git-rev-list(1). And it would be nice to have this in the
proposed "Branches and merges" tutorial (part 3?) as well.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and bzr
From: Martin Langhoff @ 2006-11-28 22:19 UTC (permalink / raw)
To: Nicholas Allen, Git Mailing List
In-Reply-To: <46a038f90611281414y165ed376r80e3dbc3c7888985@mail.gmail.com>
On 11/29/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Well, there you start depending on everyone using bzr and providing
> metadata-added patches. Git is really good at dealing with scenarios
> where not everyone is using Git.. so the
> content-is-kind-and-metadata-be-damned pays off handsomely.
content-is-KING-and-metadata-be-damned :-)
cheers,
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-28 22:16 UTC (permalink / raw)
To: Aaron Bentley; +Cc: bazaar-ng, git
In-Reply-To: <456CB13D.6090407@utoronto.ca>
Aaron Bentley wrote:
> Jakub Narebski wrote:
>> Well, I gues that with "annotate friendly" (weave or knit) storage
>> annotate/blame would be faster. But fast annotate was not one of the
>> design goals of git.
>>
>> How fast is "bzr annotate"?
>
> $ time bzr annotate builtins.py > /dev/null
>
> real 0m1.479s
> user 0m1.430s
> sys 0m0.030s
>
> builtins.py has 953 ancestor revisions (i.e. revisions that modified
> it) and 3016 lines.
>
> That's on a machine with 4141.87 Bogomips. I did optimize annotate
> slightly, but I'm submitting the optimization for our 0.14.0 release.
Hmmm... git-blame (without contents moving or rename detection) takes
around 2s user+sys on 2002 BogoMIPS machine, as compared to 1.5s
user+sys for bzr annotate on 4141.87 BogoMIPS machine.
revision.c has 1208 lines, 62 unique commits in git-blame output, 90
commits history, 102 commits full history.
--
Jakub Narebski
^ permalink raw reply
* Re: git and bzr
From: Martin Langhoff @ 2006-11-28 22:14 UTC (permalink / raw)
To: Nicholas Allen, Git Mailing List
In-Reply-To: <456CADE9.7060503@onlinehome.de>
On 11/29/06, Nicholas Allen <nick.allen@onlinehome.de> wrote:
> yes I can see if you just use plain patches. In bzr though there are
> bundles that store extra data along with the patch and if you use this
> instead of a simple patch this will never be a problem as bzr can then
> notice the same bundle being merged into 2 branches.
Well, there you start depending on everyone using bzr and providing
metadata-added patches. Git is really good at dealing with scenarios
where not everyone is using Git.. so the
content-is-kind-and-metadata-be-damned pays off handsomely.
And the "scenarios where not everyone is using Git" are everytime that
we are tracking a project that uses a different SCM. For me, the
"killer-app" of git is that, as it does not rely on magic metadata, it
is perfectly useful on projects that I track that use CVS or SVN.
I submit or commit patches upstream and git spots the commits being
echoed back in just right because it does not rely on the metadata.
Only on the content.
cheers,
martin
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-28 22:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicholas Allen, Jakub Narebski, bazaar-ng, git
In-Reply-To: <20061128215332.GK28337@spearce.org>
On Tue, 28 Nov 2006, Shawn Pearce wrote:
>
> Except when you are doing a large merge, your terminal scrollback
> is really short, and there's a lot of conflicts. Then you can't
> see what merge said about any given file. :-(
Heh. Which is partly why I just do "git diff", which usually tells me what
is up, or "git log --stat --merge", which is usually even better. I've
never actually had to scroll up.
[ But I'll also admit that I used to have a "xterm*savedlines=5000" in my
.Xdefaults, and it might be worth it for some people. I haven't actually
needed it with git, because the _real_ reason for it used to be applying
patch-sets, and I've made sure that the git patch-application is so
robust that I never need to go back and look for reasons for conflicts -
if something conflicts, it just _stops_ and undoes the whole patch
instead of continuing to apply the rest or leave the already-applied
part applied. ]
Although I agree that we could probably also improve "git status" output,
especially as I doubt it has been tested much.
People don't tend to use "git status" very much, I suspect - the most
common usage is not in "git status" itself, but simply as the commit
message template, and that one obviously cannot have any unmerged stuff at
all (since then we'd refuse to even go as far as asking for a commit
message in the first place).
Figuring out that the reason for a conflict is a name clash is not
necessarily possible after the merge, though: it's really up to the merge
policy to decide to merge a file cleanly or not, and the "Why" part of why
some particular merge policy decided not the resolve a file is really
internal to the policy, and not externally visible in the tree itself.
(But we can certainly see whether it was a pure content conflict or
whether it had some component of a name clash by just looking at what
stages we have for a name: so we could at least separate out the causes
for merge failures at least _partially_ in "git status")
> Fortunately its easy to back out of the merge and redo it with
> large enough scrollback, or redirecting it to a file for later
> review, but its annoying that we don't save that information off
> for later review.
I personally find "git log --merge" to be a huge timesaver. But I have to
say, I don't think I've seen more than one or two name conflicts ever, and
almost all of the true issues tend to be just regular data conflicts. So
that's what I personally care about most.
[ For the non-git users, "git log --merge" is just shorthand for a much
more complicated git revision parsing expression which boils down to:
"show all commits as they pertain to any remaining unmerged pathnames,
and only within the symmetrical set difference between the two branches
you merged". You could write it out as
git log ORIG_HEAD...MERGE_HEAD -- $(git ls-files --unmerged)
but that "git log --merge" is a much simpler shorthand for that thing.
It's not that merge conflicts are necessarily common, but when they do
happen, that's where you _really_ want the SCM to support you in
figuring out what happened ]
So with "git diff" showing a three-way diff for anything unmerged, and
"git log --merge" showing the commits that caused the problems, I don't
think I've ever really needed to go back and say "ok, so why did that
fail".
It's just that "git status" was never what I'd have used in the first
place. I guess it's been long enough since I used CVS that "git status"
doesn't even enter my mind all that much on a merge failure.
^ permalink raw reply
* [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Eric Wong @ 2006-11-28 22:06 UTC (permalink / raw)
To: Junio C Hamano, Pazu; +Cc: Seth Falcon, git
finish_report does seem to return a useful value indicating success
or failure, so we'll just set a flag when close_edit is called
(it is not called on failures, nor is abort_edit) and check
the flag before proceeding.
Thanks to Pazu for pointing this out.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 7942bba..c3ad5ec 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2941,6 +2941,9 @@ sub libsvn_fetch_delta {
$reporter->set_path('', $last_rev, 0, @lock, $pool);
$reporter->finish_report($pool);
$pool->clear;
+ unless ($ed->{git_commit_ok}) {
+ die "SVN connection failed somewhere...\n";
+ }
libsvn_log_entry($rev, $author, $date, $msg, [$last_commit]);
}
@@ -3195,6 +3198,9 @@ sub libsvn_new_tree {
$reporter->set_path('', $rev, 1, @lock, $pool);
$reporter->finish_report($pool);
$pool->clear;
+ unless ($ed->{git_commit_ok}) {
+ die "SVN connection failed somewhere...\n";
+ }
} else {
open my $gui, '| git-update-index -z --index-info' or croak $!;
libsvn_traverse($gui, '', $SVN->{svn_path}, $rev);
@@ -3501,7 +3507,8 @@ sub abort_edit {
sub close_edit {
my $self = shift;
- close $self->{gui} or croak;
+ close $self->{gui} or croak $!;
+ $self->{git_commit_ok} = 1;
$self->SUPER::close_edit(@_);
}
--
1.4.4.1.ge151
^ permalink raw reply related
* Re: git and bzr
From: Nicholas Allen @ 2006-11-28 22:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0611281346490.4244@woody.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 28 Nov 2006, Nicholas Allen wrote:
>> and here's how it looked in git:
>> git status
>
> Ehh. It told you exactly what happened when you actually did the merge,
> didn't it?
>
> Yeah, "git status" won't tell you _why_ it results in unmerged paths, but
> the merge will have told you. You must have seen that, but decided to
> just ignore it and not post it, because it didn't support the conclusion
> you wanted to get, did it?
I didn't do this deliberately - it's just because merge spewed out a
whole load of stuff at me that I didn't understand and therefore
overlooked the conflict message in it. I wasn't expecting to see it here
anyway and was hoping for a short and informative summary that I would
understand when I did a status.
Also what happens if I loose the messages because they scrolled off
screen or the power goes down, I need to reboot for some reason, or I
don't have time and want to shutdown my computer restart another day and
resolve the conflicts then? All useful conflict status is lost isn't it?
That's why I expected git status to tell me this in some understandable
manner and was not even expecting it to only be in the merge output....
^ permalink raw reply
* Re: git and bzr
From: Aaron Bentley @ 2006-11-28 21:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <200611281943.40354.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Well, I gues that with "annotate friendly" (weave or knit) storage
> annotate/blame would be faster. But fast annotate was not one of the
> design goals of git.
>
> How fast is "bzr annotate"?
$ time bzr annotate builtins.py > /dev/null
real 0m1.479s
user 0m1.430s
sys 0m0.030s
builtins.py has 953 ancestor revisions (i.e. revisions that modified it)
and 3016 lines.
That's on a machine with 4141.87 Bogomips. I did optimize annotate
slightly, but I'm submitting the optimization for our 0.14.0 release.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFbLE90F+nu1YWqI0RAlkdAJ99Ca4ITlwx+TuGvBmux0HPDpx28QCfTY0h
lJYpnpcpWs8SpAP31x48NF4=
=EDXr
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-28 21:53 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn Pearce, skimo, Andreas Ericsson, Yann Dirson, Steven Grimm,
git
In-Reply-To: <Pine.LNX.4.64.0611281614450.20138@iabervon.org>
On Tue, 28 Nov 2006, Daniel Barkalow wrote:
>
> I don't think you'd ever want the same commit message for commits in two
> projects.
I don't know about "ever", but yes, I do think submodule commits are
generally totally separate things from supermodule commits.
> In any case where you'd commit a submodule in the process of
> committing a supermodule, git would do this by recursively calling
> git-commit, which would prompt for separate commit messages.
That certainly works, although I'm not convinved that it's necessarily a
hugely important detail.
I suspect there may well be more important things UI-wise wrt submodules
than the "you may have to commit submodules separately" question.
For example, doing a "git pull" is a lot more interesting, since that
actually has the potential of having to resolve conflicts in submodules
before the supermodule can be committed. Getting all the "git reset"
behaviour right for when you decide "oops, that was too complicated" is
probably a lot more important than whether you have to have a separate
"commit subproject" phase for the simple cases of doing a bog-standard
"git commit -a".
^ permalink raw reply
* Re: git and bzr
From: Shawn Pearce @ 2006-11-28 21:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicholas Allen, Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0611281346490.4244@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> There are lots of reasons why "git status" may tell you that something
> isn't merged. The most common one by far being an actual data conflict,
> not a name conflict. The reason for why something conflicts is always told
> at merge-time.
Except when you are doing a large merge, your terminal scrollback
is really short, and there's a lot of conflicts. Then you can't
see what merge said about any given file. :-(
Fortunately its easy to back out of the merge and redo it with
large enough scrollback, or redirecting it to a file for later
review, but its annoying that we don't save that information off
for later review.
--
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-28 21:49 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <456CA981.4010808@onlinehome.de>
On Tue, 28 Nov 2006, Nicholas Allen wrote:
>
> and here's how it looked in git:
> git status
Ehh. It told you exactly what happened when you actually did the merge,
didn't it?
Yeah, "git status" won't tell you _why_ it results in unmerged paths, but
the merge will have told you. You must have seen that, but decided to
just ignore it and not post it, because it didn't support the conclusion
you wanted to get, did it?
There are lots of reasons why "git status" may tell you that something
isn't merged. The most common one by far being an actual data conflict,
not a name conflict. The reason for why something conflicts is always told
at merge-time.
^ permalink raw reply
* [PATCH] shortlog: remove range check
From: René Scharfe @ 2006-11-28 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8xhv2uj1.fsf@assigned-by-dhcp.cox.net>
Don't force the user to specify more than one revision parameter,
thus making git-shortlog behave more like git-log.
'git-shortlog master' will now produce the expected results; the
other end of the range simply is the (oldest) root commit.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index b5b13de..f1124e2 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -298,9 +298,7 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix)
if (!access(".mailmap", R_OK))
read_mailmap(".mailmap");
- if (rev.pending.nr == 1)
- die ("Need a range!");
- else if (rev.pending.nr == 0)
+ if (rev.pending.nr == 0)
read_from_stdin(&list);
else
^ permalink raw reply related
* Re: can I remove or move a tag in a remote repository?
From: Junio C Hamano @ 2006-11-28 21:46 UTC (permalink / raw)
To: Jim Meyering; +Cc: git, Johannes Schindelin
In-Reply-To: <87wt5rffbm.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Here's the problem:
> When I try to push the new tags, git-push fails:
>
> $ git-push -f --tags ssh+git://git.sv.gnu.org/srv/git/coreutils master:refs/heads/master
> updating 'refs/tags/cvs-head'
> from 2fd3fd29a8b40be695bc2327c8cd3bd33e521100
> to db18f53ffb221e9957124d8af81c11a7e350ac3b
> ...
> Total 1, written 1 (delta 0), reused 0 (delta 0)
> Unpacking 1 objects
> error: denying non-fast forward; you should pull first
>
> I get the same error also when using --force.
I think this is due to overeager receive.denyNonFastForwards
configuration setting at the repository you are pushing into.
I _think_ what receive-pack does in this case is totally wrong.
It should either:
(1) deny overwriting existing tags -- tags are meant to be
immutable so it should not allow them to be "updated"
regardless of fast-forwardness, or
(2) allow overwriting things under refs/tags/ without any
fast-forward checking. After all, a tag could point at a
tree or a blob, and there is no fast-forwardness among
trees.
The client side check in "git fetch" takes the latter viewpoint,
and I think we should be consistent with it.
Johannes, what do you think? Does the following patch look sane
to you?
---
diff --git a/receive-pack.c b/receive-pack.c
index 1a141dc..6c3de47 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -120,7 +120,7 @@ static int update(struct command *cmd)
"but I can't find it!", new_hex);
}
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
- !is_null_sha1(old_sha1)) {
+ !is_null_sha1(old_sha1) && !strncmp(name, "refs/heads/", 11)) {
struct commit *old_commit, *new_commit;
struct commit_list *bases, *ent;
^ permalink raw reply related
* Re: git and bzr
From: Jakub Narebski @ 2006-11-28 21:43 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <456CA981.4010808@onlinehome.de>
Nicholas Allen wrote:
>> Just out of curiosity: How does git handle the case where one file is
>> renamed differently in 2 branches and then the branches are repeatably
>> merged? I know that bzr handles this very well and in various tests I
>> did there were absolutely no repeated conflicts. Would git behave as
>> well in this scenario?
>>
>
> Ok - I got curious and decided to install git and try this myself.
>
> In this test I had a file hello.txt that got renamed to hello1.txt in
> one branch and hello2.txt in another. Then I merged the changes between
> the 2 branches.
>
> Here is how it looked after the merge in bzr:
>
> bzr status
> renamed:
> hello2.txt => hello1.txt
> conflicts:
> Path conflict: hello2.txt / hello1.txt
> pending merges:
> Nicholas Allen 2006-11-28 Renamed hello to hello1
>
>
> and here's how it looked in git:
> git status
> #
> # Changed but not updated:
> # (use git-update-index to mark for commit)
> #
> # unmerged: hello.txt
> # unmerged: hello1.txt
> # unmerged: hello2.txt
> # modified: hello2.txt
> #
> nothing to commit
Er? What about merge printed?
$ git pull . branch
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with c59706ee42aa7b6b2b203d4219210a684f5581f2
Merging:
8f43c37 Moved hello.txt to hello_master.txt
c59706e Moved hello.txt to hello_branch.txt
found 1 common ancestor(s):
b7d5f1a Initial commit
CONFLICT (rename/rename): Rename hello.txt->hello_master.txt in branch
HEAD rename hello.txt->hello_branch.txt in c59706e
Automatic merge failed; fix conflicts and then commit the result.
I agree that git-status output could be more helpful in the case of
merges. Well, you can always check "git ls-files --stage"
$ git ls-files --stage --abbrev
100644 18249f3 1 hello.txt
100644 18249f3 3 hello_branch.txt
100644 18249f3 2 hello_master.txt
> So git is not telling me that I have a conflict due to the same file
> being renamed differently in 2 branches - well at least not in a way I
> can comprehend anyway! Whereas bzr made this very clear. Also, in git I
> ended up with 2 files:
>
> ls
> hello1.txt hello2.txt
>
> whereas in bzr there was only one file and I just had to decide which
> name it was to be given to resolve the conflict.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and bzr
From: Martin Langhoff @ 2006-11-28 21:40 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <456C9DFF.1040407@onlinehome.de>
On 11/29/06, Nicholas Allen <nick.allen@onlinehome.de> wrote:
> Having not used git I can't really say whether git is better than bzr or
> not in this regard. I know in the kind of development I do the case
> where a file with the same name has been added independantly in 2
> different branches is a pretty rare one. Usually, when it has happened
> the files should have been 2 separate files with different names anyway
> - so bzr would have no problem with this.
Not so rare in a true DSCM scenario where people submit patches via
email or a bug tracker. Say two developers apply the same patch to
their trees, and one of them tweaks it a bit. While I don't personally
do kernel development, I understand that's reasonably common in the
linux dev team.
It also happens quite a bit if you cherry pick across branches patches
that create files.
In such cases, I find GIT does the right thing 99% of the time,
including spotting situations where the file got added at different
patchlevels in different branches.
cheers,
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Daniel Barkalow @ 2006-11-28 21:32 UTC (permalink / raw)
To: Shawn Pearce
Cc: skimo, Andreas Ericsson, Linus Torvalds, Yann Dirson,
Steven Grimm, git
In-Reply-To: <20061128211012.GJ28337@spearce.org>
On Tue, 28 Nov 2006, Shawn Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > and then it makes sense to let you do multiple commits with a single
> > command when the paths end in different modules, since that's obviously
> > what you're requesting, and then -a must do all of them.
>
> Except what if the submodules have different commit message
> standards? E.g. one requires signoff and another doesn't? Or one
> allows privately held information (e.g. its your coporate project)
> and one doesn't (e.g. its an open source project you use/contribute
> to)?
I don't think you'd ever want the same commit message for commits in two
projects. In any case where you'd commit a submodule in the process of
committing a supermodule, git would do this by recursively calling
git-commit, which would prompt for separate commit messages.
-Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox