* 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: [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: [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: 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: [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 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: 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: 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: 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: [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
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