* Re: fetching packs and storing them as packs
From: Nicolas Pitre @ 2006-10-27 2:41 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027014229.GA28407@spearce.org>
On Thu, 26 Oct 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 27 Oct 2006, Eran Tromer wrote:
> >
> > > Hi,
> > >
> > > On 2006-10-26 17:08, Nicolas Pitre wrote:
> > > > On Thu, 26 Oct 2006, Eran Tromer wrote:
> > > >> This creates a race condition w.r.t. "git repack -a -d", similar to the
> > > >> existing race condition between "git fetch --keep" and
> > > >> "git repack -a -d". There's a point in time where the new pack is stored
> > > >> but not yet referenced, and if "git repack -a -d" runs at that point it
> > > >> will eradicate the pack. When the heads are finally updated, you get a
> > > >> corrupted repository.
> > > >
> > > > And how is it different from receiving a pack through git-unpack-objects
> > > > where lots of loose objects are created, and git-repack -a -d removing
> > > > those unconnected loose objects before the heads are updated?
> > >
> > > git-repack -a -d does not touch unconnected loose objects.
> > > It removes only unconnected packed objects.
> >
> > Right.
> >
> > > Only git-prune removes unconnected loose objects, and that's documented
> > > as unsafe.
> >
> > Well, the race does exist. Don't do repack -a -d at the same time then.
>
> This is an issue for "central" repositories that people push into
> and which might be getting repacked according to a cronjob.
>
> Unfortunately I don't have a solution. I tried to come up with
> one but didn't. :-)
Just continue to explode received packs into loose objects then. It is
that simple. I said there were advantages and inconvenients to both
methods. This one is a nice example.
I won't repack from a cron job, so I don't expect to run a repack and a
fetch at the same time on my private repositories. I therefore don't
care about that race and so is the case for the vast majority of users.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Sean @ 2006-10-27 2:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027014229.GA28407@spearce.org>
On Thu, 26 Oct 2006 21:42:29 -0400
Shawn Pearce <spearce@spearce.org> wrote:
> This is an issue for "central" repositories that people push into
> and which might be getting repacked according to a cronjob.
>
> Unfortunately I don't have a solution. I tried to come up with
> one but didn't. :-)
What about creating a temporary ref before pushing, and then removing
it only after the HEAD has been updated?
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-27 2:08 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <200610270202.k9R22Wxf004208@laptop13.inf.utfsm.cl>
Dear diary, on Fri, Oct 27, 2006 at 04:02:32AM CEST, I got a letter
where "Horst H. von Brand" <vonbrand@inf.utfsm.cl> said that...
> Jakub Narebski <jnareb@gmail.com> wrote:
> > 7. Checkouts (as a noun). This probably read "Support Centralized and
> > Disconnected Centralized Workflow" but that is perhaps too wordy. Git would
> > have "No" for "Centralized"
>
> Why? We could all agree that some repository is "central" and all push/pull
> there. Or send patches by mail (or apply them via ssh). Sure, it's not CVS,
> but...
An ability to configure the tool so that the centralized workflow is
_enforced_ may be important for managers. It's stupid, but it's what is
meant there, I think.
> > 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
> > easy to use, but I have not much experiences with other SCM. I wonder why
> > Bazaar has "No" there...
>
> Extremely subjective. Easy to learn doesn't cut it either.
I don't think this column makes sense at all. I swear I've seen
*several* people that claimed GNU Arch was easy to learn/use for them!
^ permalink raw reply
* Re: [PATCH] cogito: Honor either post-commit script name; fail if both are executable
From: Petr Baudis @ 2006-10-27 2:05 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <874ptzhsjs.fsf@rho.meyering.net>
Hi!
Dear diary, on Fri, Oct 20, 2006 at 06:15:51PM CEST, I got a letter
where Jim Meyering <jim@meyering.net> said that...
> I promised this patch some time ago, made the changes,
> and then never sent them. This is slightly different
> from the current implementation in that it fails when both
> scripts are executable. Also, it factors out the script names and
> adds tests.
>
> Signed-off-by: Jim Meyering <jim@meyering.net>
I'm not sure I like this (of course, I always like additional tests,
though). The problem is that this loses a smooth upgrade path, things
suddenly break and you can't commit without having to think about fixing
your environment. We should always give users enough time for that with
deprecation warnings. So if we want to get rid of commit-post, we should
rather start printing deprecation warnings if commit-post exists, and in
few months cut commit-post off.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: VCS comparison table
From: Horst H. von Brand @ 2006-10-27 2:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehq78n$ec7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> I'd rather split "Supports Renames" into engine part (does SCM
> remember/detect that rename took place _as_ rename, not remember/detect it
> as copiying+deletion; something other than rename) and user interface part:
> can user easily deal with renames (this includes merging and viewing file
> history).
I think that what to tool does in its guts is completely irrelevant, what
is important is what the user sees. Sadly, it seems hard to describe
exactly what is meant/wanted here.
[...]
> 7. Checkouts (as a noun). This probably read "Support Centralized and
> Disconnected Centralized Workflow" but that is perhaps too wordy. Git would
> have "No" for "Centralized"
Why? We could all agree that some repository is "central" and all push/pull
there. Or send patches by mail (or apply them via ssh). Sure, it's not CVS,
but...
[...]
> 13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
> or "?" background color for Git. And add note that it is easy to script up
> porcelanish command, and to add another merge strategy. There also was
> example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
> marking.
Mostly an implementation detail for "extensible"...
[...]
> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
> easy to use, but I have not much experiences with other SCM. I wonder why
> Bazaar has "No" there...
Extremely subjective. Easy to learn doesn't cut it either.
^ permalink raw reply
* Re: [PATCH] make cg-commit --review restore original tree state afterwards
From: Petr Baudis @ 2006-10-27 2:02 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4539EB15.3050405@vilain.net>
Dear diary, on Sat, Oct 21, 2006 at 11:40:37AM CEST, I got a letter
where Sam Vilain <sam@vilain.net> said that...
> Ok, I ruined the error message.
>
> This could also do with some enhancement; if you edit hunks of the
> patch, then the numbers in the hunks could be updated so as to not make
> the patch abort. Also, if it does abort you should get the option of
> undoing everything, or editing the patch again...
>
> Will try again with this another time.
Actually, on current master you can now use internal_commit. My idea was
that you internal_commit with the local changes as X, then rollback to
HEAD, apply new patch. If you fail at this point, you can do much saner
recovery since you can reset the tree and timewarp back to X and save
the modified patch at a suitable place.
Besides, you can just timewarp the tree back to X (w/o updating HEAD) at
this point to recover the changes excluded from the committed patch!
I guess timewarping/internal_commit may look like magic to everyone but
me so if the above is unclear, just say so and I'll try to be more
thorough. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [PATCH qgit] Remove obsoleted includes
From: Petr Baudis @ 2006-10-27 1:51 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550610261147t61de387bqc591624aaa3b1282@mail.gmail.com>
Dear diary, on Thu, Oct 26, 2006 at 08:47:08PM CEST, I got a letter
where Marco Costalba <mcostalba@gmail.com> said that...
> Also small code cleanup
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
(It's whitespace-damaged.)
> ---
>
> Still unable to push to public repo :(
Hey, we're using this beautiful distributed version control system,
aren't we? :-) We could make use of it being fully distributed for once,
too - you can push to any other public repo until the original one
becomes available.
There's e.g. repo.or.cz. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Slight visual improvements to commitdiff view
From: Petr Baudis @ 2006-10-27 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, ltuikov
In-Reply-To: <7vu01qilg1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Oct 27, 2006 at 03:42:06AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > --- Jakub Narebski <jnareb@gmail.com> wrote:
> > ...
> >> Those changes might wait for proper refactoring of gitweb CSS (having
> >> for example 8px padding in one place only).
> >
> > Excellent! I'd like this explanation to be part of the
> > commit message if that patchset is committed to git.git.
>
> I'd like that kind of explanation with the patch in a single
> message when it is ready to be applied, too.
>
> I'll leave it up to you guys to decide if CSS refactoring should
> go in first (I personally feel it probably is the case, in which
> case this patch would need to be rebased I suspect).
We don't have any such patch, do we? So let anyone doing that patch take
this one into account and merge in whatever we have, I'd say.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Petr Baudis @ 2006-10-27 1:45 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andy Parkins, junkio, git
In-Reply-To: <4540F16F.4060604@shadowen.org>
Junio wrote:
> - We do not enclose a single statement in {}.
I don't think we need to enforce this rule in particular too rigorously
since in comparison with other style slips, it doesn't put you off by
unusual styling when you are reading the code, its only effect at all is
slight vertical space waste (but it isn't a pure loss anyway, for that
matter).
Dear diary, on Thu, Oct 26, 2006 at 07:33:35PM CEST, I got a letter
where Andy Whitcroft <apw@shadowen.org> said that...
> Andy Parkins wrote:
> > prune_object() in show_only mode would previously just show the path to the
> > object that would be deleted. The path the object is stored in shouldn't be
> > shown to users, they only know about sha1 identifiers so show that instead.
> >
> > Further, the sha1 alone isn't that useful for examining what is going to be
> > deleted. This patch also adds the object type to the output, which makes it
> > easy to pick out, say, the commits and use git-show to display them.
> > Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> > ---
> > builtin-prune.c | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/builtin-prune.c b/builtin-prune.c
> > index 7290e6d..e3bcf5f 100644
> > --- a/builtin-prune.c
> > +++ b/builtin-prune.c
> > @@ -16,8 +16,13 @@ static struct rev_info revs;
> >
> > static int prune_object(char *path, const char *filename, const unsigned char *sha1)
> > {
> > + char type[20];
> > +
> > if (show_only) {
> > - printf("would prune %s/%s\n", path, filename);
> > + if (sha1_object_info(sha1, type, NULL)) {
> > + strcpy( type, "unknown type" );
> > + }
> > + printf("would prune %s %s\n", sha1_to_hex( sha1 ), type );
> > return 0;
> > }
> > unlink(mkpath("%s/%s", path, filename));
>
> If we are changing the format would it not make more sense to be in the
> same order as the tool that lets you use it?
>
> I thought that was git cat-file <type> <commit-ish>
Seconded and please use just 'unknown' for the type string, so that you
can split the lines on spaces in scripts.
Besides, in what situation do we actually get the unknown output?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Shawn Pearce @ 2006-10-27 1:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Eran Tromer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610262038320.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 27 Oct 2006, Eran Tromer wrote:
>
> > Hi,
> >
> > On 2006-10-26 17:08, Nicolas Pitre wrote:
> > > On Thu, 26 Oct 2006, Eran Tromer wrote:
> > >> This creates a race condition w.r.t. "git repack -a -d", similar to the
> > >> existing race condition between "git fetch --keep" and
> > >> "git repack -a -d". There's a point in time where the new pack is stored
> > >> but not yet referenced, and if "git repack -a -d" runs at that point it
> > >> will eradicate the pack. When the heads are finally updated, you get a
> > >> corrupted repository.
> > >
> > > And how is it different from receiving a pack through git-unpack-objects
> > > where lots of loose objects are created, and git-repack -a -d removing
> > > those unconnected loose objects before the heads are updated?
> >
> > git-repack -a -d does not touch unconnected loose objects.
> > It removes only unconnected packed objects.
>
> Right.
>
> > Only git-prune removes unconnected loose objects, and that's documented
> > as unsafe.
>
> Well, the race does exist. Don't do repack -a -d at the same time then.
This is an issue for "central" repositories that people push into
and which might be getting repacked according to a cronjob.
Unfortunately I don't have a solution. I tried to come up with
one but didn't. :-)
--
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Slight visual improvements to commitdiff view
From: Junio C Hamano @ 2006-10-27 1:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, ltuikov
In-Reply-To: <780488.44315.qm@web31803.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> ...
>> Those changes might wait for proper refactoring of gitweb CSS (having
>> for example 8px padding in one place only).
>
> Excellent! I'd like this explanation to be part of the
> commit message if that patchset is committed to git.git.
I'd like that kind of explanation with the patch in a single
message when it is ready to be applied, too.
I'll leave it up to you guys to decide if CSS refactoring should
go in first (I personally feel it probably is the case, in which
case this patch would need to be rebased I suspect).
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-10-27 1:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehpuid$ch2$2@sea.gmane.org>
Dear diary, on Thu, Oct 26, 2006 at 11:19:49AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> By the way, Pasky, where one can find your changes to gitweb?
http://repo.or.cz/w/git/repo.git
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Nicolas Pitre @ 2006-10-27 0:50 UTC (permalink / raw)
To: Eran Tromer; +Cc: Junio C Hamano, git
In-Reply-To: <45413209.2000905@tromer.org>
On Fri, 27 Oct 2006, Eran Tromer wrote:
> Hi,
>
> On 2006-10-26 17:08, Nicolas Pitre wrote:
> > On Thu, 26 Oct 2006, Eran Tromer wrote:
> >> This creates a race condition w.r.t. "git repack -a -d", similar to the
> >> existing race condition between "git fetch --keep" and
> >> "git repack -a -d". There's a point in time where the new pack is stored
> >> but not yet referenced, and if "git repack -a -d" runs at that point it
> >> will eradicate the pack. When the heads are finally updated, you get a
> >> corrupted repository.
> >
> > And how is it different from receiving a pack through git-unpack-objects
> > where lots of loose objects are created, and git-repack -a -d removing
> > those unconnected loose objects before the heads are updated?
>
> git-repack -a -d does not touch unconnected loose objects.
> It removes only unconnected packed objects.
Right.
> Only git-prune removes unconnected loose objects, and that's documented
> as unsafe.
Well, the race does exist. Don't do repack -a -d at the same time then.
This race should be adressed somehow if it is really a problem. Now
that I've used index-pack in place of unpack-objects for a while, I
don't think I'll want to go back. It is simply faster to fetch, faster
to checkout, faster to repack, wastes less disk space, etc.
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Slight visual improvements to commitdiff view
From: Luben Tuikov @ 2006-10-27 0:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610270150.40100.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> First, I have removed creating empty divs. The div with number of
> changed files in git_difftree_body is added only if the message about
> number of changed files is displayed (above 10).
>
> Second, I have moved commit message body in commitdiff outside
> "page_body" div, to be together with "author_date" div with authorship
> info. The name of class was changed from "log" to more informative
> "commitdiff_log". This required some changes and additions to CSS. Now
> "commitdiff_log" div is responsible for displaying line separatring it
> from "page_body".
>
> I have added not full line above "patchset" div (between patchet and
> difftree). It is added by "patchset" div and separated by 8px padding.
>
>
> Those changes might wait for proper refactoring of gitweb CSS (having
> for example 8px padding in one place only).
Excellent! I'd like this explanation to be part of the
commit message if that patchset is committed to git.git.
Luben
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Slight visual improvements to commitdiff view
From: Jakub Narebski @ 2006-10-26 23:50 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061026233439.37073.qmail@web31811.mail.mud.yahoo.com>
Luben Tuikov wrote:
> Can you please explain what both patches actually do?
>
> "slight visual improvements to commitdiff view" leaves
> much, _much_ to be desired and is hardly a commit message
> suitable to live in git.git.
>
> Please describe what you found objectionable, why, how
> you decided to fix it and why you decided to fix it that way.
Adding difftree/whatchanged output to commitdiff view was somewhat
hasty, without taking care of details like separator between message
body and difftree, and separator between difftree and patchset.
First, I have removed creating empty divs. The div with number of
changed files in git_difftree_body is added only if the message about
number of changed files is displayed (above 10).
Second, I have moved commit message body in commitdiff outside
"page_body" div, to be together with "author_date" div with authorship
info. The name of class was changed from "log" to more informative
"commitdiff_log". This required some changes and additions to CSS. Now
"commitdiff_log" div is responsible for displaying line separatring it
from "page_body".
I have added not full line above "patchset" div (between patchet and
difftree). It is added by "patchset" div and separated by 8px padding.
Those changes might wait for proper refactoring of gitweb CSS (having
for example 8px padding in one place only).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Slight visual improvements to commitdiff view
From: Luben Tuikov @ 2006-10-26 23:34 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <200610261843.10529.jnareb@gmail.com>
Can you please explain what both patches actually do?
"slight visual improvements to commitdiff view" leaves
much, _much_ to be desired and is hardly a commit message
suitable to live in git.git.
Please describe what you found objectionable, why, how
you decided to fix it and why you decided to fix it that way.
Thanks,
Luben
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Eran Tromer @ 2006-10-26 14:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0610252333540.12418@xanadu.home>
On 2006-10-26 05:44, Nicolas Pitre wrote:
> diff --git a/receive-pack.c b/receive-pack.c
> index 1fcf3a9..7f6dc49 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -7,7 +7,7 @@
>
> static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
>
> -static const char *unpacker[] = { "unpack-objects", NULL };
> +static const char *unpacker[] = { "index-pack", "-v", "--stdin", "--fix-thin", NULL };
>
> static int report_status;
This creates a race condition w.r.t. "git repack -a -d", similar to the
existing race condition between "git fetch --keep" and
"git repack -a -d". There's a point in time where the new pack is stored
but not yet referenced, and if "git repack -a -d" runs at that point it
will eradicate the pack. When the heads are finally updated, you get a
corrupted repository.
(That's for the shell implementation of git-repack, at least. I assume
the new builtin preserves the old semantics.)
Since people run the supposedly safe "git repack -a -d" on regular
basis, this is going to bite.
Eran
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Eran Tromer @ 2006-10-26 22:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610261105200.12418@xanadu.home>
Hi,
On 2006-10-26 17:08, Nicolas Pitre wrote:
> On Thu, 26 Oct 2006, Eran Tromer wrote:
>> This creates a race condition w.r.t. "git repack -a -d", similar to the
>> existing race condition between "git fetch --keep" and
>> "git repack -a -d". There's a point in time where the new pack is stored
>> but not yet referenced, and if "git repack -a -d" runs at that point it
>> will eradicate the pack. When the heads are finally updated, you get a
>> corrupted repository.
>
> And how is it different from receiving a pack through git-unpack-objects
> where lots of loose objects are created, and git-repack -a -d removing
> those unconnected loose objects before the heads are updated?
git-repack -a -d does not touch unconnected loose objects.
It removes only unconnected packed objects.
Only git-prune removes unconnected loose objects, and that's documented
as unsafe.
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-26 21:25 UTC (permalink / raw)
To: Nicholas Allen; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <4540A1FE.4050300@ableton.com>
On Thu, Oct 26, 2006 at 01:54:38PM +0200, Nicholas Allen wrote:
> I would have thought that supports renames would also involve flagging a
> conflict when merging a file that has been renamed on 2 separate
> branches. ie 2 branches rename the file to different names and then one
> branch is merged into the other. In this situation, the user should be
> told of a rename conflict. Bzr supports this as far as I know. Not sure
> about git though as I have never used it.
It works as you expect:
$ git-init-db
$ touch foo
$ git-add foo
$ git-commit -m foo
Committing initial tree 4d5fcadc293a348e88f777dc0920f11e7d71441c
$ git-checkout -b other
$ git-mv foo bar
$ git-commit -m bar
$ git-checkout master
$ git-mv foo baz
$ git-commit -m baz$a
$ git-pull . other
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 5a1dfd32c56a24d0ef06f0e71d731fcd49d5dc6e
Merging:
76ac76ee3ce890d43648ebc009d278dc81a327e0 baz
5a1dfd32c56a24d0ef06f0e71d731fcd49d5dc6e bar
found 1 common ancestor(s):
c9e7e95de6fdbb2af06ea44cc60d1ac1a63eaad6 foo
CONFLICT (rename/rename): Rename foo->baz in branch HEAD rename foo->bar
in 5a1dfd32c56a24d0ef06f0e71d731fcd49d5dc6e
Automatic merge failed; fix conflicts and then commit the result.
^ permalink raw reply
* StGit-enabled bash-prompt
From: Robin Rosenberg @ 2006-10-26 21:17 UTC (permalink / raw)
To: git
Hi,
I added the following snippet to my .bashrc to help me keep track of what
patch I'm working on. I got annoyed at typing stg top/stg series all the
time.
This changes the bash prompt to include the current git branch and the top
stgit patch to the prompt.
Of course you will read and understand this code. I don't know how good an
idea it is to use the DEBUG trap this way.
NO WARRANTY (as always)
-- robin
if [ "$PS1" ]; then
function stgtag
{
br=$(stg branch 2>/dev/null)
top=$(stg top 2>/dev/null)
if [[ -n "$br$top" ]];then
echo " [$top@$br] "
fi
}
trap 'PS1="\u@\h$(stgtag)\w]\$ "' DEBUG
^ permalink raw reply
* [PATCH (amend)] diff-format.txt: Correct information about pathnames quoting in patch format
From: Jakub Narebski @ 2006-10-26 20:21 UTC (permalink / raw)
To: git
In-Reply-To: <200610262103.31058.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Discard previous version, please. This one should be correct.
Documentation/diff-format.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index ed4ebcb..e4520e2 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -144,8 +144,10 @@ the file that rename/copy produces, resp
dissimilarity index <number>
index <hash>..<hash> <mode>
-3. TAB, LF, and backslash characters in pathnames are
- represented as `\t`, `\n`, and `\\`, respectively.
+3. TAB, LF, double quote and backslash characters in pathnames
+ are represented as `\t`, `\n`, `\"` and `\\`, respectively.
+ If there is need for such substitution then the whole
+ pathname is put in double quotes.
combined diff format
--
1.4.3.3
^ permalink raw reply related
* [PATCH (again)] Fix show-ref usagestring
From: Lars Hjemli @ 2006-10-26 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This describes the abbreviation possibilities for git-show-ref
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Hopefully I can finally get it right :-)
builtin-show-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index f2912e8..59ac46b 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -3,7 +3,7 @@ #include "refs.h"
#include "object.h"
#include "tag.h"
-static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash] [--tags] [--heads] [--] [pattern*]";
+static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*]";
static int deref_tags = 0, show_head = 0, tags_only = 0, heads_only = 0,
found_match = 0, verify = 0, quiet = 0, hash_only = 0, abbrev = 0;
--
1.4.3.2
^ permalink raw reply related
* [PATCH] diff-format.txt: Expand information about pathnames quoting in patch format
From: Jakub Narebski @ 2006-10-26 19:03 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/diff-format.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index ed4ebcb..f980ecf 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -146,6 +146,9 @@ the file that rename/copy produces, resp
3. TAB, LF, and backslash characters in pathnames are
represented as `\t`, `\n`, and `\\`, respectively.
+ If there is need to quote pathname then the whole
+ pathname is put in double quotes, and quote characters
+ in pathname are represented as `\"`.
combined diff format
--
1.4.3.3
^ permalink raw reply related
* [PATCH] Fix show-ref usagestring
From: Lars Hjemli @ 2006-10-26 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This describes the abbreviation possibilities for git-show-ref
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-show-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index f2912e8..297343b 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -3,7 +3,7 @@ #include "refs.h"
#include "object.h"
#include "tag.h"
-static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash] [--tags] [--heads] [--] [pattern*]";
+static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]|--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*]";
static int deref_tags = 0, show_head = 0, tags_only = 0, heads_only = 0,
found_match = 0, verify = 0, quiet = 0, hash_only = 0, abbrev = 0;
--
1.4.3.2
^ permalink raw reply related
* gitweb.cgi and git instaweb
From: Aneesh Kumar K.V @ 2006-10-26 18:49 UTC (permalink / raw)
To: git
I am getting errors as below with git instaweb.
kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ git instaweb
2006-10-27 00:12:56: (log.c.75) server started
kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ [Fri Oct 27 00:12:57 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:13:21 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:13:37 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:13:58 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:14:08 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
[Fri Oct 27 00:14:08 2006] gitweb.cgi: Use of uninitialized value in open at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 1118.
fatal: ambiguous argument '': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
[Fri Oct 27 00:14:16 2006] gitweb.cgi: "our" variable $stylesheet masks earlier declaration in same scope at /home/opensource/vanilla/linux-2.6-git/.git/gitweb/gitweb.cgi line 59.
^ 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