* 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: [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: [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] 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: 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: 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: 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 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: [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: git pull opinion
From: Ralf Wildenhues @ 2007-11-06 7:34 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Aghiles, git list
In-Reply-To: <176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr>
Hello,
* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:
> On Nov 6, 2007, at 5:16 AM, Aghiles wrote:
>
>>> 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 would love it if for once in the git world, there were a pair of
commands that would do the exact opposite of each other and where the
naive newbie (me) would immediately recognize that from their names:
git stash push
git stash pop
Both applied in this order should be a no-op on both the working tree,
the index, and also the stash. There's room for extensions (pop
--keep-stash to not remove the stashed information), explicit naming of
stashes, doing multiple pops at once, and so on. Please don't add more
of the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.
Even if they're perfectly clear to git intimates, each one of them
takes precious extra time to learn due to this lack of symmetry.
Since I simply don't have the time resources to just implement that,
I'll thank you for your attention and go back to lurking mode now.
Thanks,
Ralf
^ permalink raw reply
* Re: git pull opinion
From: Alex Riesen @ 2007-11-06 7:38 UTC (permalink / raw)
To: Pierre Habouzit, Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <20071106004601.GS8939@artemis.corp>
Pierre Habouzit, Tue, Nov 06, 2007 01:46:01 +0100:
> 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.
How about merging just that "fix/new-API/... whatever" thing and not
the whole master, which should be a complete mess by now?
The way you explained it it looks like typical centralized workflow.
^ permalink raw reply
* Re: git pull opinion
From: Alex Riesen @ 2007-11-06 7:40 UTC (permalink / raw)
To: Aghiles; +Cc: Bill Lear, Junio C Hamano, git
In-Reply-To: <3abd05a90711052230y4d6151c6o3e7985a0c8e18161@mail.gmail.com>
Aghiles, Tue, Nov 06, 2007 07:30:23 +0100:
> > 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.
Git does merge with dirty working directory. It just wont touch the
changed files and stop merging if the merge requires it.
^ permalink raw reply
* Re: git pull opinion
From: Aghiles @ 2007-11-06 7:45 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git list
In-Reply-To: <176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr>
Hello,
> 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.
I think that people will use this a lot with the pull command and some
accidents will happen. I am of the opinion that the semantics of this
command must be changed.
Additionally, having "git stash [command]" and "git stash [argument]"
mixed together seems strange. One suggestion would be:
git stash store/add/create [stash-name]
git stash apply [stash-name]
git stash clear <stash-name> (accepts wildcards but no empty args)
...
- Aghiles.
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Jeff King @ 2007-11-06 7:51 UTC (permalink / raw)
To: Alex Riesen
Cc: Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <20071106072831.GA3021@steel.home>
On Tue, Nov 06, 2007 at 08:28:31AM +0100, Alex Riesen wrote:
> > 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:
Because you are then trying to apply a patch series with some patches
potentially missing? Continuing only on errno == ENOENT seems prudent.
-Peff
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Peter Karlsson @ 2007-11-06 8:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Pascal Obry, Abdelrazak Younes, Git Mailing List
In-Reply-To: <591E16CE-E303-4971-B57D-D84E883BB01D@zib.de>
Steffen Prohaska:
> Right. The experience should be good if you use binmode.
Shouldn't it be possible to fix this by sprinkling the appropriate
number of "b"s in the parameters to fopen()? Or is it more complicated
than that?
> But never use textmode. You'll not get an error right away. At first
> git seems to work. But later it reports weird errors. The experience
> is really bad. Don't do that.
I got errors almost right away when trying that (I need text mode to
interface with some other programs), so Cygwin-git is a no-go for me at
the moment. Of course, mixing msys-Git with Cygwin and ActiveState Perl
is also an interesting experience, to say the least :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.7
From: Peter Karlsson @ 2007-11-06 8:04 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git list
In-Reply-To: <8c5c35580711030408n658eb11fk19d554f0fa3b17@mail.gmail.com>
Lars Hjemli:
> cgit v0.7 (a fast webinterface for git) is now available at
>
> git://hjemli.net/pub/git/cgit
Has anyone managed to compile this for Win32? I cannot get gitweb to
work due to the Perl dependencies. When trying to compile cgit it hangs
checking the git version (or something like that, it keeps printing a
version number over and over again).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [RFC PATCH] Reduce the number of connects when fetching
From: Johannes Sixt @ 2007-11-06 8:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7v1wb4kuoc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>> ... 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.
How about:
S: here are what I have
C: I want these
C: want tags <-- new
C: I have these
S: ok, continue
C: I have these
S: ok, continue
C: I have these
S: ok, these are the tags <-- new
S: I've heard enough
C: done
S: packfile is here
The tags that the server provides are those (and only those[*]) that
reference objects in the packfile that it's going to send.
[*] This way the client doesn't have to figure out which tags it wants; as a
side-effect it won't accidentally fetch tags for objects that it happens to
have in the repository, but aren't reachable from any ref (like what used to
happen).
-- Hannes
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-06 8:20 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Pascal Obry, Abdelrazak Younes, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711060857140.8577@ds9.cixit.se>
On Nov 6, 2007, at 9:02 AM, Peter Karlsson wrote:
> Steffen Prohaska:
>
>> Right. The experience should be good if you use binmode.
>
> Shouldn't it be possible to fix this by sprinkling the appropriate
> number of "b"s in the parameters to fopen()? Or is it more complicated
> than that?
It's more complicated. I tried. But others convinced me that
it's harder than you think. The interfacing with other programs
through shell scripts is one major problem. Another difficulty
is that Cygwin's textmode is deprecated. So, the Cygwin guys
won't help. Search the list archives for more details.
>> But never use textmode. You'll not get an error right away. At first
>> git seems to work. But later it reports weird errors. The experience
>> is really bad. Don't do that.
>
> I got errors almost right away when trying that (I need text mode to
> interface with some other programs), so Cygwin-git is a no-go for
> me at
> the moment.
Same for me. You're welcome to join the msysgit effort ;)
But do not expect too much from my side. For me the only
priority is to get the core git commands running. Everything
that is needed to support a git-only workflow has top priority.
Everything else has lowest priority. I'll refuse to put work
into the scripts interfacing with other SCMs and I'll refuse
to work on things needed to setup a git 'server', like git-shell.
> Of course, mixing msys-Git with Cygwin and ActiveState Perl
> is also an interesting experience, to say the least :-)
I can imagine that. If you already have some new insights how
to handle such a situration it would be interesting if you
could share some of them.
Steffen
^ permalink raw reply
* Re: git pull opinion
From: Pierre Habouzit @ 2007-11-06 8:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <20071106073841.GB3021@steel.home>
[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]
On Tue, Nov 06, 2007 at 07:38:41AM +0000, Alex Riesen wrote:
> Pierre Habouzit, Tue, Nov 06, 2007 01:46:01 +0100:
> > 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.
>
> How about merging just that "fix/new-API/... whatever" thing and not
> the whole master, which should be a complete mess by now?
No master only holds simple patches (few of them, typically half a
dozen a day), or long-lived branches that are tested and ready to merge.
> The way you explained it it looks like typical centralized workflow.
Well I disagree, it's /part/ centralized. We have a two speed devel
method, one that works the old-centralized way for quick fixes, and a
more decentralized approach for big changes. It's a rather nice and
useful middle ground for a company where all programmers are within
earshot.
--
·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: [RFC PATCH] Reduce the number of connects when fetching
From: Junio C Hamano @ 2007-11-06 8:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Daniel Barkalow, git
In-Reply-To: <47302218.3060409@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> The tags that the server provides are those (and only those[*]) that
> reference objects in the packfile that it's going to send.
>
> [*] This way the client doesn't have to figure out which tags it
> wants; ...
Yes, but that shifts the burden to the sending side which is
always bad. We want to make the client work as much as possible
when it is practical.
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.7
From: Lars Hjemli @ 2007-11-06 8:44 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0711060903070.8577@ds9.cixit.se>
On Nov 6, 2007 9:04 AM, Peter Karlsson <peter@softwolves.pp.se> wrote:
> Lars Hjemli:
>
> > cgit v0.7 (a fast webinterface for git) is now available at
> >
> > git://hjemli.net/pub/git/cgit
>
> Has anyone managed to compile this for Win32?
If (win32 == cygwin): yes, just did (but it needed a makefile tweak
regarding iconv)
--
From: Lars Hjemli <hjemli@gmail.com>
Date: Tue, 6 Nov 2007 09:35:07 +0100
Subject: [PATCH] Makefile: link with libiconv if NEEDS_LIBICONV is defined
This seems to be needed to compile on cygwin.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Makefile | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 6abd82a..dbc34a2 100644
--- a/Makefile
+++ b/Makefile
@@ -19,6 +19,11 @@ OBJECTS = shared.o cache.o parsing.o html.o
ui-shared.o ui-repolist.o \
ui-snapshot.o ui-blob.o ui-tag.o ui-refs.o
+ifdef NEEDS_LIBICONV
+ EXTLIBS += -liconv
+endif
+
+
.PHONY: all git install clean distclean force-version get-git
all: cgit git
--
1.5.3.4.452.g09149
^ permalink raw reply related
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Steven Grimm, git
In-Reply-To: <7vode8j7o5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]
On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
> 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.
Well, I don't really know how closely you read #git, but I'd say that
"how do I undo my local changes in a git repository" is among the top 3
questions. There _IS_ an UI issue for that.
If git revert <commitish> -- path1 path2 path3 is going to work at some
point, I see no harm in saying that git revert HEAD -- path1 path2 path3
work. We can also in that case spit an error message:
error: this works as a courtesy but you really meant git checkout -- path/to/file
On some other issues I'm all about educating people and learning to
them how to "think different". But here it's a pure interface problem,
and git is the sole $scm with a revert commands that doesn't reverts
local changes wrt HEAD.
The next release of master will have tons of UI improvements (terse
output, better options parsing, more builtins hence faster commands …),
I believe it's stopping halfway not thinking about issues like this from
a newcomer point of view.
On the pure theoretical basis I believe you're right, it's a bit
mixing apples and oranges. On the pragmatic usability side I'm quite
sure you're wrong, because everyone is used to that:
$ hg revert --help | head -3 | tail -1
revert files or dirs to their states as of some revision
$ bzr help revert | head -1
Purpose: Revert files to a previous revision.
$ svn help revert | head -1
revert: Restore pristine working copy file (undo most local edits).
$ darcs help revert | head -3 | tail -1
Revert to the recorded version (safe the first time only).
<put your favorite non-git scm with a revert command here>
--
·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: Pierre Habouzit @ 2007-11-06 8:51 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Aghiles, git list
In-Reply-To: <176851C5-D735-4DDC-B799-A5106CD03989@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
On Tue, Nov 06, 2007 at 05:29:58AM +0000, Benoit Sigoure wrote:
> 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.
no it's a command issue. git stash <random non command name> should
_NOT_ be an alias to git stash save <random name>. Either the command
should be mandatory _or_ it should be a long option to avoid such kind
of conflicts.
It's just a bad ui design.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/
From: Gerrit Pape @ 2007-11-06 8:54 UTC (permalink / raw)
To: Alex Riesen
Cc: Fernando J. Pereda, git, Junio C Hamano, Jakub Narebski,
Jeff King, Alex Riesen
In-Reply-To: <20071105225258.GC4208@steel.home>
When saving patches to a maildir with e.g. mutt, the files are put into
the new/ subdirectory of the maildir, not cur/. This makes git-am state
"Nothing to do.". This patch lets git-mailsplit additional check new/
after reading cur/.
This was reported by Joey Hess through
http://bugs.debian.org/447396
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
> > + for (i = 0; i < 2; ++i) {
> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
I made the array NULL-terminated.
On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
> Isn't the subject line now wrong?
Yes, thanks.
On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
> Why is missing "cur" (or "new", for that matter) a fatal error?
> Why is it error at all? How about just ignoring the fact?
As suggested by Jeff, I made it ignore the error on ENOENT.
builtin-mailsplit.c | 38 ++++++++++++++++++++++----------------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 74b0470..46b27cd 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -101,20 +101,29 @@ static int populate_maildir_list(struct path_list *list, const char *path)
{
DIR *dir;
struct dirent *dent;
+ char name[PATH_MAX];
+ char *subs[] = { "cur", "new", NULL };
+ char **sub;
+
+ for (sub = subs; *sub; ++sub) {
+ snprintf(name, sizeof(name), "%s/%s", path, *sub);
+ if ((dir = opendir(name)) == NULL) {
+ if (errno == ENOENT)
+ continue;
+ error("cannot opendir %s (%s)", name, strerror(errno));
+ return -1;
+ }
- if ((dir = opendir(path)) == NULL) {
- error("cannot opendir %s (%s)", path, strerror(errno));
- return -1;
- }
+ while ((dent = readdir(dir)) != NULL) {
+ if (dent->d_name[0] == '.')
+ continue;
+ snprintf(name, sizeof(name), "%s/%s", *sub, dent->d_name);
+ path_list_insert(name, list);
+ }
- while ((dent = readdir(dir)) != NULL) {
- if (dent->d_name[0] == '.')
- continue;
- path_list_insert(dent->d_name, list);
+ closedir(dir);
}
- closedir(dir);
-
return 0;
}
@@ -122,19 +131,17 @@ static int split_maildir(const char *maildir, const char *dir,
int nr_prec, int skip)
{
char file[PATH_MAX];
- char curdir[PATH_MAX];
char name[PATH_MAX];
int ret = -1;
int i;
struct path_list list = {NULL, 0, 0, 1};
- snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
- if (populate_maildir_list(&list, curdir) < 0)
+ if (populate_maildir_list(&list, maildir) < 0)
goto out;
for (i = 0; i < list.nr; i++) {
FILE *f;
- snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
+ snprintf(file, sizeof(file), "%s/%s", maildir, list.items[i].path);
f = fopen(file, "r");
if (!f) {
error("cannot open mail %s (%s)", file, strerror(errno));
@@ -152,10 +159,9 @@ static int split_maildir(const char *maildir, const char *dir,
fclose(f);
}
- path_list_clear(&list, 1);
-
ret = skip;
out:
+ path_list_clear(&list, 1);
return ret;
}
--
1.5.3.5
^ permalink raw reply related
* Re: git pull opinion
From: Andreas Ericsson @ 2007-11-06 8:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <Pine.LNX.4.64.0711060115130.4362@racer.site>
Johannes Schindelin wrote:
> 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.
>
I must have missed it. Found the thread now though. Gonna try the patch in
production for a while and see how it pans out.
I'm curious about this hunk though. It seems unaffiliated with the --rebase
option as such, but was still in the patch. Would you care to clarify?
@@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- curr_branch=$(git symbolic-ref -q HEAD)
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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