* Re: [PATCH] t5530-upload-pack-error: Check more carefully for failures.
From: Junio C Hamano @ 2007-11-06 0:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711052240.12822.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Monday 05 November 2007 21:05, Junio C Hamano wrote:
> > > The test case checks for failures in rev-list (a missing
> > > object). Any hints how to trigger a failure in pack-objects
> > > that does not also trigger in rev-list would be welcome.
> >
> > How about removing a blob from the test repository to corrupt
> > it? rev-list --objects I think would happily list the blob
> > because it sees its name in its containing tree without checking
> > its existence.
>
> That does it. This goes on top of my previous patch.
Thanks. Will squash with further changes attached for readability.
---
t/t5530-upload-pack-error.sh | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/t/t5530-upload-pack-error.sh b/t/t5530-upload-pack-error.sh
index 70d4f86..cc8949e 100755
--- a/t/t5530-upload-pack-error.sh
+++ b/t/t5530-upload-pack-error.sh
@@ -6,6 +6,13 @@ test_description='errors in upload-pack'
D=`pwd`
+corrupt_repo () {
+ object_sha1=$(git rev-parse "$1") &&
+ ob=$(expr "$object_sha1" : "\(..\)") &&
+ ject=$(expr "$object_sha1" : "..\(..*\)") &&
+ rm -f ".git/objects/$ob/$ject"
+}
+
test_expect_success 'setup and corrupt repository' '
echo file >file &&
@@ -15,7 +22,7 @@ test_expect_success 'setup and corrupt repository' '
test_tick &&
echo changed >file &&
git commit -a -m changed &&
- rm -f .git/objects/5e/a2ed416fbd4a4cbe227b75fe255dd7fa6bd4d6
+ corrupt_repo HEAD:file
'
@@ -35,7 +42,7 @@ test_expect_success 'upload-pack fails due to error in pack-objects' '
test_expect_success 'corrupt repo differently' '
git hash-object -w file &&
- rm -f .git/objects/be/c63e37d08c454ad3a60cde90b70f3f7d077852
+ corrupt_repo HEAD^^{tree}
'
^ permalink raw reply related
* Re: git pull opinion
From: Bill Lear @ 2007-11-06 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aghiles, git
In-Reply-To: <7vd4uomfn8.fsf@gitster.siamese.dyndns.org>
On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
>Aghiles <aghilesk@gmail.com> writes:
>
>> Is there an "easier" way to pull into a dirty directory ? I am
>> asking this to make sure I understand the problem and not
>> because I find it annoying to type those 4 commands to perform
>> a pull (although some of my colleagues do find that annoying :).
>
>You need to switch your mindset from centralized SVN workflow.
>
>The beauty of distributedness is that it redefines the meaning
>of "to commit". In distributed systems, the act of committing
>is purely checkpointing and it is not associated with publishing
>the result to others as centralized systems force you to.
>
>Stop thinking like "I need to integrate the changes from
>upstream into my WIP to keep up to date." You first finish what
>you are currently doing, at least to the point that it is
>stable, make a commit to mark that state, and then start
>thinking about what other people did. You may most likely do a
>"git fetch" followed by "git rebase" to update your WIP on top
>of the updated work by others.
>
>Once you get used to that, you would not have "a dirty
>directory" problem.
I respectfully beg to differ. I think it is entirely reasonable, and
not a sign of "centralized" mindset, to want to pull changes others
have made into your dirty repository with a single command.
Bill
^ permalink raw reply
* Re: [PATCH] gc: use parse_options
From: Junio C Hamano @ 2007-11-06 0:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: James Bowes, git
In-Reply-To: <472FA26E.4060706@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Junio C Hamano wrote:
>> James Bowes <jbowes@dangerouslyinc.com> writes:
>>
>>> + struct option builtin_gc_options[] = {
>>> + OPT_BOOLEAN(0, "prune", &prune, "prune unused objects"),
>>
>> I would write "unreferenced loose" instead of "unused" here...
>
> It is not just "loose" objects here, but also unreferenced objects in packs,
> since the "-a" option to repack is now only used when --prune is specified.
> Without --prune, "-A" is supplied to repack instead.
>
> So maybe the message should just be "prune unreferenced objects"
Fair enough, will do.
^ permalink raw reply
* Re: git pull opinion
From: Steven Grimm @ 2007-11-06 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aghiles, git
In-Reply-To: <7vd4uomfn8.fsf@gitster.siamese.dyndns.org>
On Nov 5, 2007, at 3:33 PM, Junio C Hamano wrote:
> Aghiles <aghilesk@gmail.com> writes:
>
>> Is there an "easier" way to pull into a dirty directory ? I am
>> asking this to make sure I understand the problem and not
>> because I find it annoying to type those 4 commands to perform
>> a pull (although some of my colleagues do find that annoying :).
>
> You need to switch your mindset from centralized SVN workflow.
I don't think wanting to pull in the middle of one's work has anything
to do with centralized vs. decentralized, actually, though I do agree
that it's a question of workflow.
For maybe 80% of my work, I do things "the git way" (lots of little
local commits) and only sync up with other people when I've reached a
good stopping point. Those are cases where I'm working in isolation on
a new feature or a fix and will publish it as a whole unit when I'm
done.
But the other 20% of the time, I'm working closely with another
person. For example, I might be working with a front-end developer who
is writing some nice snazzy JavaScript or Flash UI code to talk to my
server-side code. And in that case, I really do want to be able to
pull down his latest changes while I'm still in the middle of working
on my own stuff, not least because it's only by testing with the real
client -- where the button to invoke a particular piece of code on my
side has just been added in the last 2 minutes -- that I can decide
whether my work in progress is actually functional or not. (Unit tests
only get you partway there.)
In other words, for traditional open-source-style distributed
development where each repository is an isolated island that goes off
and does its own thing, ignoring the outside world, the recommended
git workflow is totally appropriate. It's also appropriate for a lot
of in-house non-distributed development.
But for some classes of collaboration, where two or more people are
essentially editing the same code base to work on the same feature and
their changes are highly interdependent, that workflow is next to
useless. There *is* no "I've gotten my code working and am ready to
look at other people's changes now" stage until pretty late in the
game. This kind of workflow happens a lot in commercial development in
my experience.
Before git-stash, I did a lot of "commit; fetch; rebase; reset"
sequences to support this kind of tight collaboration. Now it's
"stash; fetch; rebase; unstash" which is the same number of commands
but is semantically clearer. "fetch; rebase --dirty" or "pull --dirty -
s rebase" will be nicer.
-Steve
^ permalink raw reply
* Re: git pull opinion
From: Pierre Habouzit @ 2007-11-06 0:46 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, Aghiles, git
In-Reply-To: <18223.46848.109961.552827@lisa.zopyra.com>
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
On Tue, Nov 06, 2007 at 12:36:16AM +0000, Bill Lear wrote:
> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
> > Stop thinking like "I need to integrate the changes from upstream
> > into my WIP to keep up to date."
> >
> > [...]
> >
> > Once you get used to that, you would not have "a dirty directory"
> > problem.
>
> I respectfully beg to differ. I think it is entirely reasonable, and
> not a sign of "centralized" mindset, to want to pull changes others
> have made into your dirty repository with a single command.
I agree, I have such needs at work. Here is how we (very informally)
work: people push things that they believe could help other (a new
helper function, a new module, a bug fix) in our master ASAP, but
develop big complex feature in their repository and merge into master
when it's ready.
Very often we discuss some bugfix that is impeding people, or a
most-wanted-API. Someone does the work, commits, I often want to merge
master _directly_ into my current work-branch, because I want the
fix/new-API/... whatever.
I don't believe it's because we have a centralized repository that I
have those needs, I would have the very same if I pulled changes
directly from my colleagues repository. The reason why I need it at work
is because there are some very vivid kind of changes, that only takes a
couple of diff lines, and that you _need_ for your work to be completed.
It's not really a matter of being fully up-to-date.
Though to my delight, with the current tip-of-next git, I noticed that
many rebase and pull work in a dirty tree now :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git pull opinion
From: Andreas Ericsson @ 2007-11-06 0:54 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, Aghiles, git
In-Reply-To: <18223.46848.109961.552827@lisa.zopyra.com>
Bill Lear wrote:
> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
>> Aghiles <aghilesk@gmail.com> writes:
>>
>>> Is there an "easier" way to pull into a dirty directory ? I am
>>> asking this to make sure I understand the problem and not
>>> because I find it annoying to type those 4 commands to perform
>>> a pull (although some of my colleagues do find that annoying :).
>> You need to switch your mindset from centralized SVN workflow.
>>
>> The beauty of distributedness is that it redefines the meaning
>> of "to commit". In distributed systems, the act of committing
>> is purely checkpointing and it is not associated with publishing
>> the result to others as centralized systems force you to.
>>
>> Stop thinking like "I need to integrate the changes from
>> upstream into my WIP to keep up to date." You first finish what
>> you are currently doing, at least to the point that it is
>> stable, make a commit to mark that state, and then start
>> thinking about what other people did. You may most likely do a
>> "git fetch" followed by "git rebase" to update your WIP on top
>> of the updated work by others.
>>
>> Once you get used to that, you would not have "a dirty
>> directory" problem.
>
> I respectfully beg to differ. I think it is entirely reasonable, and
> not a sign of "centralized" mindset, to want to pull changes others
> have made into your dirty repository with a single command.
>
I find it much more convenient to just fetch them. I'd rather see
git-pull being given a --rebase option (which would ultimately mean
teaching git-merge about it) to rebase already committed changes on
top of the newly fetched tracking branch. It's being worked on, but
rather slowly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [BUG] git grep broken on master - won't work when merging
From: Junio C Hamano @ 2007-11-06 1:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <46a038f90711051553p6202cc62wfda6b45ff7769984@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Strange behaviour of git grep on one of the projects I hack on...
>
> $ git --version
> git version 1.5.3.5.561.g140d
>
> $ git grep LOB lib
> fatal: insanely many options to grep
>
> After a bit of head-scratching I realised I was in the middle of a
> merge, with some unresolved paths in the lib directory. A bit of
> testing shows that the unresolved index is probably the problem:
>
> $ git grep LOB lib
> fatal: insanely many options to grep
>
> # an unresolved file
> $ git grep LOB lib/accesslib.php
> fatal: insanely many options to grep
I think 36f2587ffb6802cb38071510810f48cddfc4f34a (grep: do not
skip unmerged entries when grepping in the working tree.) is the
dud one. Would this help?
diff --git a/builtin-grep.c b/builtin-grep.c
index c7b45c4..185876b 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -343,7 +343,7 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
memcpy(name + 2, ce->name, len + 1);
}
argv[argc++] = name;
- if (argc < MAXARGS && !ce_stage(ce))
+ if (argc < MAXARGS)
continue;
status = flush_grep(opt, argc, nr, argv, &kept);
if (0 < status)
^ permalink raw reply related
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: Junio C Hamano @ 2007-11-06 1:06 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Schindelin, git
In-Reply-To: <472F7B2F.4050608@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
> ...
>> Instead of allocating a separate array and freeing at the end,
>> wouldn't it make more sense to have a bitfield that records what
>> is used by the format string inside the array elements?
>
> How about (ab)using the value field? Let interp_find_active() mark
> unneeded entries with NULL, and the rest with some cookie. All table
> entries with non-NULL values need to be initialized. interp_set_entry()
> needs to be aware of this cookie, as it mustn't free() it. The cookie
> could be the address of a static char* in interpolate.c.
Sorry, where is this aversion to making the struct a bit larger
coming from?
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 1:16 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <472FBB3F.8080307@op5.se>
Hi,
On Tue, 6 Nov 2007, Andreas Ericsson wrote:
> Bill Lear wrote:
> > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
> > > Aghiles <aghilesk@gmail.com> writes:
> > >
> > > > Is there an "easier" way to pull into a dirty directory ? I am
> > > > asking this to make sure I understand the problem and not
> > > > because I find it annoying to type those 4 commands to perform
> > > > a pull (although some of my colleagues do find that annoying :).
> > > You need to switch your mindset from centralized SVN workflow.
> > >
> > > The beauty of distributedness is that it redefines the meaning
> > > of "to commit". In distributed systems, the act of committing
> > > is purely checkpointing and it is not associated with publishing
> > > the result to others as centralized systems force you to.
> > >
> > > Stop thinking like "I need to integrate the changes from
> > > upstream into my WIP to keep up to date." You first finish what
> > > you are currently doing, at least to the point that it is
> > > stable, make a commit to mark that state, and then start
> > > thinking about what other people did. You may most likely do a
> > > "git fetch" followed by "git rebase" to update your WIP on top
> > > of the updated work by others.
> > >
> > > Once you get used to that, you would not have "a dirty
> > > directory" problem.
> >
> > I respectfully beg to differ. I think it is entirely reasonable, and
> > not a sign of "centralized" mindset, to want to pull changes others
> > have made into your dirty repository with a single command.
> >
>
> I find it much more convenient to just fetch them. I'd rather see
> git-pull being given a --rebase option (which would ultimately mean
> teaching git-merge about it) to rebase already committed changes on
> top of the newly fetched tracking branch. It's being worked on, but
> rather slowly.
git-pull learning about --rebase does not mean teaching git-merge about
it. See my patch, which you (and others) failed to enthusiastically
embrace, which is the sole reason it is stalled.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] t3502: Disambiguate between file and rev by adding --
From: Brian Gernhardt @ 2007-11-06 1:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071105222530.GA4208@steel.home>
On Nov 5, 2007, at 5:25 PM, Alex Riesen wrote:
> Brian Gernhardt, Sun, Nov 04, 2007 16:31:26 +0100:
>> This test failed because git-diff didn't know if it was asking for
>> the
>> file "a" or the branch "a". Adding "--" at the end of the ambiguous
>> commands allows the test to finish properly.
>
> To be precise: this is ambiguous only on case-challenged filesystems
Oh. I just saw the ambiguous error. Should I re-post with a more
correct commit message?
~~B
^ permalink raw reply
* Re: [PATCH] t3502: Disambiguate between file and rev by adding --
From: Junio C Hamano @ 2007-11-06 1:20 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Alex Riesen, git
In-Reply-To: <2DC3CFEE-ACA0-448F-9957-EB98F299D812@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Nov 5, 2007, at 5:25 PM, Alex Riesen wrote:
>
>> Brian Gernhardt, Sun, Nov 04, 2007 16:31:26 +0100:
>>> This test failed because git-diff didn't know if it was asking for
>>> the
>>> file "a" or the branch "a". Adding "--" at the end of the ambiguous
>>> commands allows the test to finish properly.
>>
>> To be precise: this is ambiguous only on case-challenged filesystems
>
> Oh. I just saw the ambiguous error. Should I re-post with a more
> correct commit message?
This is what I wrote but haven't pushed out (I will have to tend
other topics first):
commit 9f12bec4386fc96e5b617268822cbb75e4c76101
Author: Brian Gernhardt <benji@silverinsanity.com>
Date: Sun Nov 4 10:31:26 2007 -0500
t3502: Disambiguate between file and rev by adding --
On a case insensitive file system, this test fails because git-diff
doesn't know if it is asking for the file "A" or the tag "a".
Adding "--" at the end of the ambiguous commands allows the test to
finish properly.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Minor glitch in git-gui: changes to global options aren't taken into account immediately
From: Benoit SIGOURE @ 2007-11-06 1:30 UTC (permalink / raw)
To: git list
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
Hi list,
[git-gui version 0.8.4
git version 1.5.3.4.398.g859b
Tcl/Tk version 8.4.7
OSX 10.4.10]
I've just realized that git-gui wasn't only using 3 lines of context
in the diffs so I changed the setting under the menu Wish>Options...
under the section `Global'. I had to restart git-gui so that the new
setting is taken into account. Admittedly, it's a minor
inconvenience, but I thought I'd let you know, in case one of the Tcl/
Tk hackers out there want to fix it :-)
Also, when I click the green `+' to maximize the size of the window
of git-gui, it doesn't do anything.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Michael Cohen @ 2007-11-06 1:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: Gerrit Pape, Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <20071105225258.GC4208@steel.home>
On Nov 5, 2007, at 5:52 PM, Alex Riesen wrote:
> Gerrit Pape, Mon, Nov 05, 2007 13:49:20 +0100:
>> + for (i = 0; i < 2; ++i) {
>> + snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
>> + if ((dir = opendir(name)) == NULL) {
>> + error("cannot opendir %s (%s)", name, strerror(errno));
>> + return -1;
>> + }
>
> Why is missing "cur" (or "new", for that matter) a fatal error?
> Why is it error at all? How about just ignoring the fact?
In Maildir format, cur and new hold the mails. :P
-mjc
^ permalink raw reply
* Re: [RFC PATCH] Reduce the number of connects when fetching
From: Junio C Hamano @ 2007-11-06 1:51 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711041614390.7357@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The idea is to keep the open connection in the data for the transport in
> between getting the list of refs and doing anything further. This
> therefore moves the connection-handling aspects outside of fetch-pack()
> and handles them primarily in transport.c.
The idea is very sound. The scripted version of git-fetch used
a separate ls-remote only because peek-remote and fetch-pack
were separate programs.
> ... In particular, I don't know if there's a way to have the
> connection end up in a state where objects for more refs can be requested
> after some refs have been requested and the resulting objects read.
The upload-pack protocol goes "S: here are what I have, C: I
want these, C: I have these, S: ok, continue, C: I have these,
S: ok, continue, C: I have these, S: ok, I've heard enough, C:
done, S: packfile is here", so after packfile generation starts
there is nothing further the downloader can say.
Otherwise you would be able to do the tag following using the
same connection, but that is unfortunately not a case.
^ permalink raw reply
* Re: [BUG] git grep broken on master - won't work when merging
From: Martin Langhoff @ 2007-11-06 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vlk9ckwyn.fsf@gitster.siamese.dyndns.org>
On 11/6/07, Junio C Hamano <gitster@pobox.com> wrote:
> I think 36f2587ffb6802cb38071510810f48cddfc4f34a (grep: do not
> skip unmerged entries when grepping in the working tree.) is the
> dud one. Would this help?
Works great here! Thanks!
cheers,
martin
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Junio C Hamano @ 2007-11-06 2:22 UTC (permalink / raw)
To: Yin Ping; +Cc: Junio C Hamano, git
In-Reply-To: <46dff0320711040517r6da5d7aaid849ff06df1b5bb6@mail.gmail.com>
"Yin Ping" <pkufranky@gmail.com> writes:
> However, in some cases these messages are helpful. And a third kind of
> cases is that people care about only part of all submodules.
>
> So, maybe some an switch can be used to turn this on or off (default
> off)?
I personally think that is overengineering. Isn't having/not
having the submodule directory cloned a good enough indicator
of which submodules are interested in by the user?
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 2:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711052325090.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In the same way, I would expect "git revert <commit> -- file" to undo the
> changes in that commit to _that_ file (something like "git merge-file
> file <commit>:file <commit>^:file"), but this time commit it, since it
> was committed at one stage.
Allowing people to revert or cherry pick partially by using
paths limiter is a very good idea; the whole "it comes from a
commit so we also commit" feels an utter nonsense, though.
^ permalink raw reply
* Re: [RFC PATCH] Reduce the number of connects when fetching
From: Daniel Barkalow @ 2007-11-06 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wb4kuoc.fsf@gitster.siamese.dyndns.org>
On Mon, 5 Nov 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > The idea is to keep the open connection in the data for the transport in
> > between getting the list of refs and doing anything further. This
> > therefore moves the connection-handling aspects outside of fetch-pack()
> > and handles them primarily in transport.c.
>
> The idea is very sound. The scripted version of git-fetch used
> a separate ls-remote only because peek-remote and fetch-pack
> were separate programs.
I figured that had to be the case, due to the way the protocol acts at the
beginning.
> > ... In particular, I don't know if there's a way to have the
> > connection end up in a state where objects for more refs can be requested
> > after some refs have been requested and the resulting objects read.
>
> The upload-pack protocol goes "S: here are what I have, C: I
> want these, C: I have these, S: ok, continue, C: I have these,
> S: ok, continue, C: I have these, S: ok, I've heard enough, C:
> done, S: packfile is here", so after packfile generation starts
> there is nothing further the downloader can say.
>
> Otherwise you would be able to do the tag following using the
> same connection, but that is unfortunately not a case.
It would be nice if this could continue: "C: I also want these, S: ok,
heard enough, C: done, S: another packfile is here"; we should be able to
identify the end of the packfile on both ends to resume doing other
things.
Or, maybe, "C: I also want these single objects, S: here's a thin pack of
them", since it's exclusively tags pointing to objects we have just
gotten.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vsl3kjdct.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > In the same way, I would expect "git revert <commit> -- file" to undo
> > the changes in that commit to _that_ file (something like "git
> > merge-file file <commit>:file <commit>^:file"), but this time commit
> > it, since it was committed at one stage.
>
> Allowing people to revert or cherry pick partially by using paths
> limiter is a very good idea; the whole "it comes from a commit so we
> also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
You can always add the "-n" option.
Ciao,
Dscho
^ permalink raw reply
* Re: Minor glitch in git-gui: changes to global options aren't taken into account immediately
From: Johannes Schindelin @ 2007-11-06 3:19 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list
In-Reply-To: <93FD01F4-71F8-4025-BA7F-A642E2B7CAD6@lrde.epita.fr>
Hi,
On Tue, 6 Nov 2007, Benoit SIGOURE wrote:
> I've just realized that git-gui wasn't only using 3 lines of context in the
> diffs so I changed the setting under the menu Wish>Options... under the
> section `Global'. I had to restart git-gui so that the new setting is taken
> into account.
Would not clicking on another file have done the trick, too?
Ciao,
Dscho
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-06 3:26 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Pierre Habouzit, Nicolas Pitre, Git ML
In-Reply-To: <Pine.LNX.4.64.0711051803231.7357@iabervon.org>
On Mon, Nov 05, 2007 at 06:46:08PM -0500, Daniel Barkalow wrote:
> - if (!args.dry_run && remote && ret == 0) {
> + if (!args.dry_run && remote && ret != -4) {
> for (ref = remote_refs; ref; ref = ref->next)
> update_tracking_ref(remote, ref);
> }
>
> That is, -2 means that we've done less than was asked, but nothing blew
> up; -4 means something blew up. When we skip something, we drop peer_ref
> from it, so there's nothing to update (and it's dropped from the set of
> mappings, in case we cared further about it with respect to reporting the
> actions we actually took). Then we update all refs that were acted on if
> ret isn't -4, and we return non-zero if ret is either -2 or -4.
This is OK, I guess. But it really doesn't accomplish the useful thing
we might get by noting per-ref errors, which is that we _can_ update the
tracking refs for those refs where it is appropriate.
We would have to parse the lines from receive_status and match them with
refs. I started a patch to do this, but I wonder if it is really worth
it. I would think that 99% of the time you have a failure at the sending
level, it's because the connection is broken, and you have no idea
_which_ refs were updated anyway, and you have to assume that none were.
So perhaps it is OK to just treat the two classes of errors differently,
and only cover per-ref errors for the "-2" case.
-Peff
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -N option to force a new import
From: Matt McCutchen @ 2007-11-06 3:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzz51d7.fsf@gitster.siamese.dyndns.org>
On Wed, 2007-10-24 at 20:17 -0700, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>
> > I had a git repository for development of rsync and wanted to start
> > importing the upstream CVS with git-cvsimport, but git-cvsimport saw
> > that the git repository existed and insisted on updating a previous
> > import. This patch adds an -N option to git-cvsimport to force a new
> > import and updates the documentation appropriately.
>
> Sounds like a useful addition. Tests?
Good call! As I was dismayed to discover, the existing files in the
working tree confused the import, so -N as I implemented it is useless.
I ended up doing the import a different way; I'll notify the list if I
get around to implementing -N properly.
Matt
^ permalink raw reply
* Re: git pull opinion
From: Aghiles @ 2007-11-06 4:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4uomfn8.fsf@gitster.siamese.dyndns.org>
Hello Junio,
> You need to switch your mindset from centralized SVN workflow.
Yes, we understood that and we are trying hard :)
> The beauty of distributedness is that it redefines the meaning
> of "to commit". In distributed systems, the act of committing
> is purely checkpointing and it is not associated with publishing
> the result to others as centralized systems force you to.
>
This is very nice actually and we absolutely understand what a
commit means in the git world. Having the commit as a step
before publishing is very helpful (although some concepts such
as "staging for a commit" are still obscure as of now).
> Stop thinking like "I need to integrate the changes from
> upstream into my WIP to keep up to date." You first finish what
> you are currently doing, at least to the point that it is
> stable, make a commit to mark that state, and then start
> thinking about what other people did.
One particular situation in which this might not apply is when
two people work very closely on the same feature (as mentioned
by Steve Grimm in this thread) and one needs the changes
made by the other. This often happens when starting a new project,
as it is our case now :)
Thank you,
- Aghiles.
^ permalink raw reply
* Re: git pull opinion
From: Aghiles @ 2007-11-06 4:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071105234049.GA31277@genesis.frugalware.org>
Hello,
> who will run git stash clear? :)
Yes you are right. By the way, in the context of merging into a
dirty tree, "git stash clear" seems to be a dangerous command:
there is a risk of loosing all your changes without a question
asked!
I know unix is a harsh world but ...
- Aghiles.
^ permalink raw reply
* Re: git pull opinion
From: Aghiles @ 2007-11-06 4:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711060007010.4362@racer.site>
Hello,
> The consense was that you are much better off committing first, then
> pulling. And if the work you are doing really is not committable, but you
> _have_ to pull _now_, you use stash. Although you are quite likely to
> revert the pull when it succeeds, and _then_ unstash.
Sorry but I don't really understand why one should "revert the pull" ? Could
elaborate for a newbie ? :)
- Aghiles.
^ 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