* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Alex Riesen @ 2007-11-06 7:28 UTC (permalink / raw)
To: Michael Cohen; +Cc: Gerrit Pape, Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <635FFEC2-2489-443B-8425-DF2B58BE23C2@mac.com>
Michael Cohen, Tue, Nov 06, 2007 02:41:56 +0100:
> 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
So? Why *STOP* reading the mails if just one of the directories could
not be opened? IOW, I suggest:
+ for (i = 0; i < 2; ++i) {
+ snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
+ dir = opendir(name);
+ if (!dir)
+ continue;
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Björn Steinbrink @ 2007-11-06 6:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kristian Høgsberg, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711052317170.4362@racer.site>
On 2007.11.05 23:18:36 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Nov 2007, Bj?rn Steinbrink wrote:
>
> > On 2007.11.05 13:57:53 -0500, Kristian H?gsberg wrote:
> >
> > > The shell script just has
> > >
> > > case "$all,$interactive,$also,$#" in
> > > *t,*t,*)
> > > die "Cannot use -a, --interactive or -i at the same time." ;;
> > >
> > > which doesn't seem to care about the value of $also. As far as I
> > > understand git commit, it doesn't make sense to pass any of -a, -i, -o
> > > or --interactive at the same time so I guess I could join the checks
> >
> > Note that there are only two commas. The asterisks catch everything and
> > $# won't be "t", so that catches anything with at least two t's.
>
> So shouldn't it be
>
> if (!!all + !!interactive + !!also > 1)
>
> Hmm?
Ah, yeah, that's the short and sweet version, I always forget about the
conversion to bool giving you 0/1 values... ;-)
Note though, that Kristian had a similar check at the end of his email,
that included "only" (but lacked the bool conversion). The original
reason why I thought that it would be better was that for example
"git commit --all --only foo" didn't care about "only" at all. But that
actually was because the --all + paths usage check was broken. So the
fixed version actually refuses to use accept that, but with a (IMHO) not
so good error message:
$ git commit -a -o file
Paths with -a does not make sense.
Given that some people are used to just pass -a all the time, they might
just automatically pass it together with -o. And I think that we
actually want to tell them that -a + -o makes no sense instead. Just
like we do for -a + -i, which is kind of the complementary usage error.
So I'd go for a correct version of Kristian's suggestion:
if (!!also + !!only + !!all + !!interactive > 1)
die("Only one of --include/--only/--all/--interactive can be used.");
Björn
^ permalink raw reply
* Re: git pull opinion
From: Aghiles @ 2007-11-06 6:30 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
In-Reply-To: <18223.46848.109961.552827@lisa.zopyra.com>
> 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.
BitKeeper, for example, does a merge with a "dirty" directory.
I am not saying that git should behave the same way but I think
that this argument strengthens the point that it is not a
"centralized repository" mindset.
- Aghiles.
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Junio C Hamano @ 2007-11-06 5:30 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: git, johannes.schindelin
In-Reply-To: <20071106050512.GA6768@mediacenter.austin.rr.com>
Shawn Bohrer <shawn.bohrer@gmail.com> writes:
> On Mon, Nov 05, 2007 at 01:14:32PM -0800, Junio C Hamano wrote:
>> Shawn Bohrer <shawn.bohrer@gmail.com> writes:
>> [...]
>> > +static int disabled = 1;
>>
>> This means we are committed to make clean.requireForce default
>> to true, which is fine by me. I need to warn the users about
>> this early.
>
> Actually I don't care either way, but in my last rebase on next this
> change was already made to git-clean.sh so I adjusted accordingly.
Oh, that was not a question to you, but a note to me.
>> > +static int show_only = 0;
>> > +static int remove_directories = 0;
>> > +static int quiet = 0;
>> > +static int ignored = 0;
>> > +static int ignored_only = 0;
>>
>> Please do not explicitly initialize static variables to zero.
>
> I realize that static variables will be automatically initialized to
> zero so this is unnecessary, but is there some technical reason not to
> initialize explicitly? If the answer is simply a style preference that
> is fine, I'm just here to learn.
Both readability and style have to do much with this.
The style has a historical background which is a slight
technical merit. It results in a smaller executable file, as C
compilers traditionally placed file-scope static variables that
are not explicitly initialized in the BSS section, instead of
explicitly storing N-bytes of zero as the the initial data in it
(although I do not see a reason for compilers not to do the same
for variables explicitly initialized to zero. In fact, I think
modern gcc produces the same allocation with or without "= 0"
initialization).
> Of course as already pointed out these don't actually need to be static
> in the first place so I'll simply move them into cmd_clean(). This does
> lead me to another question though. Now that Dscho has converted my
> patch to use parse-options, what is the best way to update my patch
> while still giving credit to Dscho?
Please send a rewritten replacement version as a single patch
that is cleanly applicable to 'next', and mention people whose
input helped you in polishing the patch in the proposed commit
log message.
^ permalink raw reply
* Re: git pull opinion
From: Benoit Sigoure @ 2007-11-06 5:29 UTC (permalink / raw)
To: Aghiles; +Cc: git list
In-Reply-To: <3abd05a90711052016s615cd66cy5a5f932900d89143@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Nov 6, 2007, at 5:16 AM, Aghiles wrote:
> 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 ...
Be *very* careful, because it's worse than that. If you run, say,
`git stash clean', instead of `clear' (that's the sort of typo that
quickly slips through), then it will stash all your changes in a new
stash named "clean". Once you realize you made a typo, you will most
probably correct it and run `git stash clear' but... Oops, you just
wiped your changes that were in the "clean" stash.
That happened to me and other people I know, so now I'm utterly
cautious when I start a command with "git stash".
As far as I remember, a patch was proposed to change this mis-
behavior of "git stash" (one could argue that it's a PEBCAK issue,
but I really think this command is *way* too dangerous) but I don't
think it's been accepted at this time.
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] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-06 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin
In-Reply-To: <7vejf4pf7r.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 05, 2007 at 01:14:32PM -0800, Junio C Hamano wrote:
> Shawn Bohrer <shawn.bohrer@gmail.com> writes:
> [...]
> > +static int disabled = 1;
>
> This means we are committed to make clean.requireForce default
> to true, which is fine by me. I need to warn the users about
> this early.
Actually I don't care either way, but in my last rebase on next this
change was already made to git-clean.sh so I adjusted accordingly.
> > +static int show_only = 0;
> > +static int remove_directories = 0;
> > +static int quiet = 0;
> > +static int ignored = 0;
> > +static int ignored_only = 0;
>
> Please do not explicitly initialize static variables to zero.
I realize that static variables will be automatically initialized to
zero so this is unnecessary, but is there some technical reason not to
initialize explicitly? If the answer is simply a style preference that
is fine, I'm just here to learn.
Of course as already pointed out these don't actually need to be static
in the first place so I'll simply move them into cmd_clean(). This does
lead me to another question though. Now that Dscho has converted my
patch to use parse-options, what is the best way to update my patch
while still giving credit to Dscho?
^ permalink raw reply
* Re: [RFC PATCH] Reduce the number of connects when fetching
From: Junio C Hamano @ 2007-11-06 5:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711052150340.7357@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>
>> 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...
You would need a protocol extension for this, as the protocol
defines all the remainder after the have-ack exchange to be
intended for unpack-objects, not just the data for a single pack
that immediately follows the exchange. Mysteriously,
unpack-objects even has code to write out the remainder after
the pack data.
The protocol extension would probably need to depend on the
existence of sideband. Make the sending side signal the end of
the pack data over the sideband after sending a pack, and then
both sides can go back to the "C: I want these too, S: Ok, here
it is" exchange. You may optionally want to do another have-ack
exchange here, but for the purpose of tag following I suspect
there is no need for that.
^ 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 4:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711060317220.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>
>> 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.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
^ 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
* 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: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: [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: [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: 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: [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: [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: 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: [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: [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: [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: [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
* 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] 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
* 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: 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
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