* Re: [PATCH] blame: allow -L n,m to have an m bigger than the file's line count
From: Jay Soffian @ 2010-02-10 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <7v8wb098kv.fsf@alter.siamese.dyndns.org>
On Wed, Feb 10, 2010 at 2:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> That is extremely sad.
For you, I'll see what I can do. I don't like the maintainer to be grumpy. :-)
j.
^ permalink raw reply
* Re: [PATCH] git-archive documentation: .gitattributes must be committed
From: René Scharfe @ 2010-02-10 20:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francois Marier, git, Nguyen Thai Ngoc Duy
In-Reply-To: <7v1vgsao21.fsf@alter.siamese.dyndns.org>
Am 10.02.2010 20:27, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>>> +The .gitattributes file must be present in the named tree for it to take
>>> +effect. Uncommitted attributes will not be considered in exports.
>>> +
>>> EXAMPLES
>>> --------
>>> git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
>>
>> Yeah, the description of --worktree-attributes is a bit terse. The
>> lines you add make it appear almost as if this switch doesn't exist,
>> though; perhaps add a "unless --worktree-attributes is given" or similar
>> to one of the new sentences?
>
> My impression has always been that people use attributes with archive more
> often to _tweak_ how the archive is produced after the fact, and they do
> so by modifying checked out .gitattributes (or $GIT_DIR/info/attributes)
> than allowing a possibly stale .gitattributes file etched in stone^Wtree
> being archived. So in that sense, probably --worktree-attributes should
> have been the default.
That was the case up to ba053ea9 (April 2009, archive: do not read
.gitattributes in working directory). I think that the current
behaviour makes sense because it provides a repeatable default.
René
^ permalink raw reply
* Re: [Announce] bup 0.09: git-based backup system for really huge datasets
From: Avery Pennarun @ 2010-02-10 20:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <m3sk998lhq.fsf@localhost.localdomain>
On Wed, Feb 10, 2010 at 4:54 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> bup is a file backup tool based on the git packfile format.
> [...]
>> bup is still pretty experimental, but it's already a useful tool for
>> backing up your files, even if those files include millions of files
>> and hundreds of gigs of VM images.
>>
>> You can find the source code (and README) at github:
>>
>> http://github.com/apenwarr/bup
>>
>> To subscribe to the bup mailing list, send an email to:
>>
>> bup-list+subscribe@googlegroups.com
>>
>> Looking forward to everyone's feedback.
>
> Would you be adding short info about your project to
> http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
Done. Thanks for the reminder!
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] git-archive documentation: .gitattributes must be committed
From: Junio C Hamano @ 2010-02-10 20:18 UTC (permalink / raw)
To: René Scharfe; +Cc: Francois Marier, git, Nguyen Thai Ngoc Duy
In-Reply-To: <4B731043.6010108@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> ... I think that the current
> behaviour makes sense because it provides a repeatable default.
I wouldn't insist on changing the default again too strongly, but I think
the --worktree-attributes option should be advertised better in the
documentation, as that mode of operation seems to match what the users
expect better, and I think that is how this thread started.
^ permalink raw reply
* Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"
From: Björn Gustavsson @ 2010-02-10 20:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl3i137f.fsf@alter.siamese.dyndns.org>
2010/2/9 Junio C Hamano <gitster@pobox.com>:
> I actually changed my mind after thinking about it a bit more.
Thanks for thinking more about it and for your explanation
about the algorithm
I am quite busy at the moment, but I hope to get started
on a patch series after the end of February.
> I'd like to see this logic (and only this logic, without relying on the
> diff hunk offset numbers at all) done first, because it is very much in
> line with what we already do, and more importantly, because it is a more
> general solution that is applicable outside the context of rebase.
I'll try to implement that logic. It seems that it should cover
99% of all real-world use cases. I will not worry about the general
case (tons of blanks) until I have got the first patch working.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* GSoC 2010
From: Sverre Rabbelier @ 2010-02-10 20:23 UTC (permalink / raw)
To: Johannes Schindelin, Daniel Barkalow, Eric Wong, Jeff King,
Shawn O. Pearce
Heya,
Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a
bit sad at the moment (only two idea's). Part of the reason Git was
listed as 'example application' before was our awesome idea list, we
should live up to that again this year :). If you feel like mentoring
a summer of code student, or if you have a great idea, please add it
to the list so that our would-be students have some variety in
choosing their projects. I just added "A remote helper for svn" [1]
myself, since I would love to see native svn support in git. Would
either Daniel or Eric (or someone else of course) be interested in
being a co- or backup-mentor for this project?
Also, unless Shawn volunteers again, we need a Summer of Code admin
for this year. Dscho, Peff, as you two have both jumped in for Junio
before, do either of you have the time and inclination to do so if
Shawn cannot? And of course, Shawn, do you have time to admin again
this year? If not, (and no-one else steps up) I'm willing to admin
myself, but I'll also be backup-admin and mentor for Melange, so if at
all possible it would be awesome if someone else jumps in.
Anyway, Summer of Code 2010 is a go [2], now is the time to get ready
and prepare for an awesome summer :).
[0] http://git.wiki.kernel.org/index.php/SoC2010Ideas
[1] http://git.wiki.kernel.org/index.php/SoC2010Ideas#A_remote_helper_for_svn
[2] http://socghop.appspot.com/
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCHv2 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching
From: Jakub Narebski @ 2010-02-10 20:32 UTC (permalink / raw)
To: Petr Baudis
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <201002101922.50010.jnareb@gmail.com>
Dnia środa 10. lutego 2010 19:22, Jakub Narebski napisał:
> Well, the idea was to use PerlIO::Util if possible, checking it via
>
> out $use_perlio_layers = eval { require PerlIO::Util; 1 };
>
> and fallback to generic mechanism if it is not present. Only the
> generic mechanism would have to be changed from manipulating *STDOUT
> (*STDOUT = $data_fh etc.) to tied filehandle.
Well, damn, this is not needed[1]. Instead of manipulating *STDOUT,
it is enough to use 'select FILEHANDLE'. It means that the capture
would look like this:
open my $data_fh, '>', \$data;
my $oldfh = select($data_fh);
# ... code that uses 'print <sth>'
select($oldfh);
close $data_fh;
One thing that needs to be done is changing 'binmode STDOUT ...' into
'binmode select() ...'
[1] Thanks to mst on #perl channel for pointing this to me.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-archive documentation: .gitattributes must be committed
From: Junio C Hamano @ 2010-02-10 20:33 UTC (permalink / raw)
To: Francois Marier; +Cc: René Scharfe, git, Nguyen Thai Ngoc Duy
In-Reply-To: <7vr5os7sl2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> ... I think that the current
>> behaviour makes sense because it provides a repeatable default.
>
> I wouldn't insist on changing the default again too strongly, but I think
> the --worktree-attributes option should be advertised better in the
> documentation, as that mode of operation seems to match what the users
> expect better, and I think that is how this thread started.
How about this? Instead of stopping at saying "it is taken from the tree
and must be committed, period", we should continue giving insn to help
people who didn't do so to achieve what they want to do.
-- >8 --
Subject: archive documentation: attributes are taken from the tree by default
By default, git-archive takes attributes from the tree being archived.
People however often wonder why their attempts to affect the way how the
command archives their tree by changing .gitattributes in their work tree
fail.
Add a bit of explanatory note to tell them how to achieve what they want
to do.
Noticed-by: Francois Marier
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-archive.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 799c8b6..8d3e666 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -112,6 +112,14 @@ export-subst::
expand several placeholders when adding this file to an archive.
See linkgit:gitattributes[5] for details.
+Note that attributes are by default taken from the `.gitattributes` files
+in the tree that is being archived. If you want to tweak the way the
+output is generated after the fact (e.g. you committed without adding an
+appropriate export-ignore in its `.gitattributes`), adjust the checked out
+`.gitattributes` file as necessary and use `--work-tree-attributes`
+option. Alternatively you can keep necessary attributes that should apply
+while archiving any tree in your `$GIT_DIR/info/attributes` file.
+
EXAMPLES
--------
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
^ permalink raw reply related
* git cherry-pick --continue?
From: Sverre Rabbelier @ 2010-02-10 20:37 UTC (permalink / raw)
To: Git List
Heya,
At the moment git cherry-pick stands out from the sequencer tools in
that it doesn't support --continue but requires you to manually supply
the '-c ...' argument to 'git commit' when there's a conflict instead.
Is it desirable that we add such an option? And if so, how would one
go about implementing it?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [msysGit] upload-pack timing issue on windows?
From: Jay Soffian @ 2010-02-10 20:41 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Sixt, msysgit, Git Mailing List
In-Reply-To: <40aa078e1002080318n16918f91r5a5f4cd9b76a8436@mail.gmail.com>
On Mon, Feb 8, 2010 at 6:18 AM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> On Sat, Feb 6, 2010 at 11:18 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:
>>> However, I have tracked down a bit of what goes on in the client.
>>> There's a call to read_in_full, called from pack-write.c, line 246
>>> that fails in the failure-case, but not in the success-case. This is
>>> where the client expects "pack\tSHA-1" or "keep\tSHA-1". There "fatal:
>>> early EOF"-messages seems to originate from index-pack.c, line 197.
>>> This is the first line of code in parse_pack_header(), it's also
>>> AFAICT the first call-site for any read(0, <...>) (though fill()).
>>
>> This looks like upload-pack died without sending enough to fill a pack header.
>>
>> Try merging this branch:
>>
>> git://repo.or.cz/git/mingw/j6t.git async-in-thread
>>
>> It contains your changes to start_async plus a refinement of die() when it is
>> called from the async procedure (it passes t5530, for example). It is also
>> converted to pthreads, and therefore also works on Unix. The new
>> implementation of start_async is more careful about the file handles, though
>> not so much on Windows.
>>
>> If there's no change for you, then you could look into implementing
>> fcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this
>> branch, using Get/SetHandleInformation().
>>
>
> Thanks a lot. I tried merging it, but the issue still pops up. I also
> tried to implement fcntl(F_GETFD/SETFD, FD_CLOEXEC), still no dice.
> I'm not entirely sure if I did it correctly, though.
I have no idea if it's related, but a similar thing seems to happen
with git under cygwin-1.7.1.
http://article.gmane.org/gmane.os.cygwin/114032
This is when cloning/fetching over ssh. I've not personally seen the
problem, but I compile git from source. Coworkers who are using the
cygwin-1.7.1 provided git see the problem consistently.
j.
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Jeff King @ 2010-02-10 21:04 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e1002101237i60a0b2c5j6d1e52b33dacbaa2@mail.gmail.com>
On Wed, Feb 10, 2010 at 09:37:10PM +0100, Sverre Rabbelier wrote:
> At the moment git cherry-pick stands out from the sequencer tools in
> that it doesn't support --continue but requires you to manually supply
> the '-c ...' argument to 'git commit' when there's a conflict instead.
> Is it desirable that we add such an option? And if so, how would one
> go about implementing it?
I think it makes sense. It is perhaps a little iffy to use "continue"
when you are not really continuing on to further cherry-picks (and in a
rebase, continue is not just about resolving conflicts, but about
continuing to the next item in the rebase). Cherry-picks are more like
"am --resolved"[1].
But semantic nitpicks aside, I think "continue" is a good enough name.
The differences between what it means for each command are fairly
obvious based on the command, and there is real value in a user just
having to remember one verb.
-Peff
[1] On the other hand, I usually mistype that as "git am --continue",
which _does_ make sense, since you are applying a sequence of patches.
Maybe "am" should support both.
^ permalink raw reply
* Re: [PATCH] Documentation: reword --thin description
From: Nicolas Pitre @ 2010-02-10 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <7vsk98apcr.fsf@alter.siamese.dyndns.org>
On Wed, 10 Feb 2010, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > .... But --thin turned
> > out to be re-enabled by default for pushes by mistake on a few occasions
> > when the affected code has been reworked. No idea what state it is now,
> > and I don't think that makes such a difference on the server in the end.
>
> Hmmmm... it's doubly bad that the maintainer does not recall these
> few occasions that mistakes happened.
The default was changed in commit a4503a15af. Seems that today --thin
is on by default again. I don't think we should care that much,
especially as --thin would logically have to be the default when pushing
to a bundle. Obviously leaving it off for push and on for fetch is
creating needless confusion.
Nicolas
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Jeff King @ 2010-02-10 21:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
In-Reply-To: <20100210210419.GA7728@coredump.intra.peff.net>
On Wed, Feb 10, 2010 at 04:04:19PM -0500, Jeff King wrote:
> [1] On the other hand, I usually mistype that as "git am --continue",
> which _does_ make sense, since you are applying a sequence of patches.
> Maybe "am" should support both.
Hmm. I was thinking "am" was the odd man out, but really there are only
two sequencer commands that I noted: rebase and am. So you could perhaps
argue that rebase should also learn "--resolved". Or am I forgetting
one?
I find the patch below convenient. I dunno if anybody else actually
cares.
-- >8 --
Subject: [PATCH] am: allow --continue as a synonym for --resolved
Rebase calls this same function "--continue", which means
users may be trained to type it. There is no reason to
deprecate --resolved (or -r), but adding this synonym is
friendly to users.
Signed-off-by: Jeff King <peff@peff.net>
---
git-am.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c8b9cbb..88cef39 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -26,6 +26,7 @@ patch-format= format the patch(es) are in
reject pass it through git-apply
resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
+continue synonym for --resolved
skip skip the current patch
abort restore the original branch and abort the patching operation.
committer-date-is-author-date lie about committer date
@@ -318,7 +319,7 @@ do
scissors=t ;;
--no-scissors)
scissors=f ;;
- -r|--resolved)
+ -r|--resolved|--continue)
resolved=t ;;
--skip)
skip=t ;;
--
1.7.0.rc2.22.g0716c.dirty
^ permalink raw reply related
* Re: git cherry-pick --continue?
From: Sverre Rabbelier @ 2010-02-10 21:26 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git List
In-Reply-To: <20100210212408.GB7728@coredump.intra.peff.net>
Heya,
On Wed, Feb 10, 2010 at 22:24, Jeff King <peff@peff.net> wrote:
> I find the patch below convenient. I dunno if anybody else actually
> cares.
I do, it's useful when applying a bunch of patches and conflicts arise
:). Typing 'git am --continue' is what I'm used to from 'git rebase'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [RFC] submodule+shallow clone feature request
From: Schuyler Duveen @ 2010-02-10 21:39 UTC (permalink / raw)
To: git
My use case is deploying from a git repository, which would be even more
graceful with the following features:
1. When 'git clone' has both --recursive and --depth, then submodules
are also checked out shallow (for speed/bandwidth).
2. Some way to specify an override on .gitmodules sources. This is
because our .gitmodules includes public, read-only sources (github),
rather than our local repos we would prefer to deploy from (for the
purpose of reliability).
The other use-case for feature #2 is the read-only vs. writable
repository sources. Developers that are also working on the submodules
should be able to clone from separate repository sources. Though this
could be (and perhaps is) satisfied with a pushurl= in .gitmodules, I'd
like to keep the push url non-public, and that still would leave us
unable to deploy from different urls.
For #2 maybe something like this:
$ git clone --recursive --depth 1 --modules foo.modules\
> git@example.com/foo.git
where foo.modules contains:
<begin>
[submodule "bar"]
path = bar
url = git@example.com/bar.git
[submodule "bar/baz"]
path = bar/baz
url = git@example.com/baz.git
<end>
Notice how the .gitmodules needs to be able to specify recursive sources
as well. Presumably `git submodule init` would take --modules argument
as well (and maybe git submodule update, too).
I'm not well-versed in the git source code yet, but poking around
suggests that this is doable. Would a patch be well received (or does
someone want to do it for me :-)
cheers,
sky
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Junio C Hamano @ 2010-02-10 22:01 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Junio C Hamano, Git List
In-Reply-To: <20100210212408.GB7728@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmm. I was thinking "am" was the odd man out, but really there are only
> two sequencer commands that I noted: rebase and am. So you could perhaps
> argue that rebase should also learn "--resolved". Or am I forgetting
> one?
I don't think you are forgetting anything, except that "am" came first with
"resolved".
The focus of the verb is "I declare I am finished marking the resolution".
Taking that declaration and continuing is ultimately "am"'s decision. IOW
the user is not telling "am" to continue---the difference is subtle, but
it was a conscious design decision.
"rebase --continue" came later, and I think its focus is placed more
heavily on the instruction side ("Please continue"), and not on the
declaration side ("I now have marked the resolution for all paths").
This causes people sometimes to want to see it "continue", even when then
haven't marked the resolved paths as resolved. I personally think the
focus is misplaced.
But that is just a philosophical difference ;-).
^ permalink raw reply
* Re: [RFC] submodule+shallow clone feature request
From: Avery Pennarun @ 2010-02-10 22:10 UTC (permalink / raw)
To: Schuyler Duveen; +Cc: git
In-Reply-To: <4B73277C.9010801@columbia.edu>
On Wed, Feb 10, 2010 at 4:39 PM, Schuyler Duveen <sky@columbia.edu> wrote:
> 2. Some way to specify an override on .gitmodules sources. This is
> because our .gitmodules includes public, read-only sources (github),
> rather than our local repos we would prefer to deploy from (for the
> purpose of reliability).
You can already override this by editing .git/config after running
'git submodule init'. Of course, doing so precludes using --recursive
in "git clone."
> I'm not well-versed in the git source code yet, but poking around
> suggests that this is doable. Would a patch be well received (or does
> someone want to do it for me :-)
The git-submodule stuff is rarely maintained. I expect patches that
improve it will meet with generally positive response, but it's
somewhat unlikely that anyone will write them for you.
Have fun,
Avery
^ permalink raw reply
* Re: [RFC] submodule+shallow clone feature request
From: Junio C Hamano @ 2010-02-10 22:14 UTC (permalink / raw)
To: Schuyler Duveen; +Cc: git
In-Reply-To: <4B73277C.9010801@columbia.edu>
Schuyler Duveen <sky@columbia.edu> writes:
> My use case is deploying from a git repository, which would be even more
> graceful with the following features:
>
> 1. When 'git clone' has both --recursive and --depth, then submodules
> are also checked out shallow (for speed/bandwidth).
>
> 2. Some way to specify an override on .gitmodules sources. This is
> because our .gitmodules includes public, read-only sources (github),
> rather than our local repos we would prefer to deploy from (for the
> purpose of reliability).
These should be doable if you do not use --recursive, so I don't think
they are insurmountable issues. I suspect many people would welcome such
enhancements to the "git submodule" potty.
I think the current implementation of "--recursive" is an attempt to help
people with a particular view (all submodules are interesting and the user
needs an access to them immediately) while not trying to help others with
different needs. Contribution from the latter class of users to change
the situation would be good.
^ permalink raw reply
* git rebase -i and the reflog
From: Sverre Rabbelier @ 2010-02-10 22:19 UTC (permalink / raw)
To: Git List
Heya,
I use "git rebase -i" a lot, and as a result the output from 'git log
-g' and 'git reflog' is a tad messy. That is, it's (afaik) not
possible to check that after my rebasing did not mess things up using
something like 'git diff HEAD@{1}'. I could of course tag the old head
or something, but that's not the only problem, due to the clutter it's
hard to find genuine commits. What I want is a way to see HEAD's
movement _excluding_ any rebase activity. So if I change history from
A-o-B-C to A-o-B'-C', I want to see C and C' in the reflog, but not
B', since B' is often actually identical to B, the only reason that it
changed is that I did 'git rebase -i' on some far-back commit.
Is there an existing solution to this?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Junio C Hamano @ 2010-02-10 22:21 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <7v63644uoq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> Hmm. I was thinking "am" was the odd man out, but really there are only
>> two sequencer commands that I noted: rebase and am. So you could perhaps
>> argue that rebase should also learn "--resolved". Or am I forgetting
>> one?
Having said all I did in the previous message, I think "am --continue"
would be a good addition.
And "rebase --resolved" would not make any sense if the reason the control
is given back to you was because you ran "rebase -i" and marked a commit
to be "edit"ed. Of course, we could add "--resolved" and "--edited" (or
perhaps "--amended") to "rebase", and have it make sure that the correct
one is given. For example, when it stopped for "edit", it would reject
"rebase --resolved". But I do not think it is worth the hassle.
^ permalink raw reply
* Re: git rebase -i and the reflog
From: Junio C Hamano @ 2010-02-10 22:23 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e1002101419x40844a42s21108aaa849430c1@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I use "git rebase -i" a lot, and as a result the output from 'git log
> -g' and 'git reflog' is a tad messy. That is, it's (afaik) not
> possible to check that after my rebasing did not mess things up using
> something like 'git diff HEAD@{1}'.
Yes and no. I too suffer from it but only when I rebase a detached HEAD
state. If you rebased a topic, "git diff topic@{1}" (or "git diff @{1}")
would give you what you want.
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Sverre Rabbelier @ 2010-02-10 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git List
In-Reply-To: <7vbpfw3f6t.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Feb 10, 2010 at 23:21, Junio C Hamano <gitster@pobox.com> wrote:
> Having said all I did in the previous message, I think "am --continue"
> would be a good addition.
How about 'cherry-pick --resolved' though ;).
> And "rebase --resolved" would not make any sense if the reason the control
> is given back to you was because you ran "rebase -i" and marked a commit
> to be "edit"ed. Of course, we could add "--resolved" and "--edited" (or
> perhaps "--amended") to "rebase", and have it make sure that the correct
> one is given. For example, when it stopped for "edit", it would reject
> "rebase --resolved". But I do not think it is worth the hassle.
I don't see any benefit to that, in fact, I'd recommend against it.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-svn taking a long time
From: David Kågedal @ 2010-02-10 22:25 UTC (permalink / raw)
To: Andrew Myrick; +Cc: Git Mailing List
In-Reply-To: <87bpfxov6w.fsf@krank.kagedal.org>
David Kågedal <davidk@lysator.liu.se> writes:
> Andrew Myrick <amyrick@apple.com> writes:
>
>> Give 1.7.0-rc2 a try. It includes commit 8bff7c5383ed833bd1df9c8d85c00a27af3e5b02, which attempts to persistently cache a lot of the processing that git-svn has to do on subversion's merge tickets, which has improved my fetch times significantly.
>
> By "merge tickets", are you talking about the merge functionality that
> appeared in subversion 1.5? We don't use that.
>
> But I had another idea. I pecularity of our subversion repo is that we
> no longer use the foo/trunk branch, but only foo/branches/*. But we did
> once upon a time have a foo/trunk. And since I didn't include a "fetch =
> foo/trunk:refs/remotes/svn/trunk" in my config, it might need to refetch
> that information every time. For instance, the first revision is on
> trunk.
>
> I'm rerunning the fetch now with the trunk added, so see if it helps.
That seems to have done the trick. Now it's quick when there is nothing
to do.
Perhaps there is something in the git-svn caching that could still be
improved?
--
David Kågedal
^ permalink raw reply
* Re: git rebase -i and the reflog
From: Sverre Rabbelier @ 2010-02-10 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v3a183f3q.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Feb 10, 2010 at 23:23, Junio C Hamano <gitster@pobox.com> wrote:
> Yes and no. I too suffer from it but only when I rebase a detached HEAD
> state. If you rebased a topic, "git diff topic@{1}" (or "git diff @{1}")
> would give you what you want.
Ah, mhh, so the reason I'm seeing this cruft is that I'm using 'HEAD@'
instead of 'topic@'. It only makes sense that HEAD's reflog includes
every commit, and a topic's reflog includes just that topics. Thanks
for the quick reply, this'll make my life a bunch easier :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git cherry-pick --continue?
From: Junio C Hamano @ 2010-02-10 22:34 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Jeff King, Git List
In-Reply-To: <fabb9a1e1002101423y79460afdn2bc31b117195ef42@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Wed, Feb 10, 2010 at 23:21, Junio C Hamano <gitster@pobox.com> wrote:
>> Having said all I did in the previous message, I think "am --continue"
>> would be a good addition.
>
> How about 'cherry-pick --resolved' though ;).
Changing the insn to suggest using "-C topic" when the original command
line was "git cherry-pick topic" would be a good addition, too. Currently
we suggest "-c" and abbreviated object name, neither of which is sensible.
While I think "--resolved" makes sense, I do not see much benefit, and it
largely depends on what you do. If you are suggesting to commit with what
is kept in $GIT_DIR/MERGE_MSG, I would actually recommend against it. The
message will have "Conflicts:" information but that is meaningless unless
you are recording from what context the commit was cherry-picked from at
the same time.
^ 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