* Re: [PATCH 0/14] fork/exec removal series
From: Johannes Schindelin @ 2007-10-14 17:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, Johannes Sixt, gitster, git
In-Reply-To: <20071014071239.GB1198@artemis.corp>
Hi,
On Sun, 14 Oct 2007, Pierre Habouzit wrote:
> On Sun, Oct 14, 2007 at 02:58:57AM +0000, Shawn O. Pearce wrote:
>
> > But we most definately *must* continue to support fork() for the async
> > functions. Its the most common interface available on one of our
> > biggest platforms (UNIX).
>
> Yeah that, and the fact that many of the git modules aren't thread-safe
> (some modules have static buffers strbuf's or caching variables) and
> should be used with care.
I think that was exactly the point of Shawn: expose bugs on Unix that
would otherwise only show in msysGit.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Benoit SIGOURE @ 2007-10-14 17:10 UTC (permalink / raw)
To: git list; +Cc: Make Windows
In-Reply-To: <1192381040.4908.57.camel@homebase.localnet>
[-- Attachment #1.1: Type: text/plain, Size: 1254 bytes --]
Context: GNU make seems to be willing to switch from CVS to ...
something else.
On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
> [...] the big thing no one else seems to have addressed much in
> other discussions I've seen is portability. It LOOKS like there are
> native ports of GIT to MINGW, but I have no idea how complete and
> usable
> they are. If someone who has a Windows system could look into that it
> would be a big help.
I think the best thing to do is to ask directly on the Git ML.
Someone already pointed out that he'd like to use Git on Windows but
doesn't want to install either Cygwin or MSYS. Is this possible, or
will it be possible in the near future? Is it possible to use one of
the various GUIs (git-gui, gitk, qgit) on Windows without requiring a
POSIXish shell etc.?
When will the librarification of Git be finished? (if Git is
available as a library, and if this library works on Windows, it will
greatly help truly native Windows ports).
Not that I like Windows in any way, right, but it's legitimate for
people working on Windows ports of various software to be willing to
have a truly native port of Git for Windows.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
[-- Attachment #2: Type: text/plain, Size: 134 bytes --]
_______________________________________________
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mailman/listinfo/make-w32
^ permalink raw reply
* Re: [PATCH 01/14] Change git_connect() to return a struct child_process instead of a pid_t.
From: Johannes Schindelin @ 2007-10-14 17:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <200710141140.10597.johannes.sixt@telecom.at>
Hi,
On Sun, 14 Oct 2007, Johannes Sixt wrote:
> On Sunday 14 October 2007 02:57, Johannes Schindelin wrote:
> >
> > On Sat, 13 Oct 2007, Johannes Sixt wrote:
> > > -int finish_connect(pid_t pid)
> > > +int finish_connect(struct child_process *conn)
> > > {
> > > - if (pid == 0)
> > > + if (conn == NULL)
> > > return 0;
> > >
> > > - while (waitpid(pid, NULL, 0) < 0) {
> > > + while (waitpid(conn->pid, NULL, 0) < 0) {
> > > if (errno != EINTR)
> > > return -1;
> >
> > Just for completeness' sake: could you do a free(conn); before return
> > -1;?
>
> I know. But the loop is going away with the next patch, so I didn't
> bother. Can you live with that?
It'll be hard, but I'll try ;-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH amend 14/14] Use the asyncronous function infrastructure to run the content filter.
From: Johannes Sixt @ 2007-10-14 17:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0710140404480.25221@racer.site>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
On Sunday 14 October 2007 05:07, Johannes Schindelin wrote:
> On Sat, 13 Oct 2007, Johannes Sixt wrote:
> > status = finish_command(&child_process);
> > if (status)
> > - error("external filter %s failed %d", cmd, -status);
> > + error("external filter %s failed", params->cmd);
>
> Did you mean to remove the status from the output (it should probably read
> "(exit status %d)" instead of just "%d", but an exit status can help
> identify problems, right?
I didn't mean to change the error message here.
> > + if (start_async(&async))
> > + return 0; /* error was already reported */
>
> Please write "return NULL;"
This patch now does just that.
-- Hannes
convert.c | 60 +++++++++++++++++++++++++++---------------------------------
1 files changed, 27 insertions(+), 33 deletions(-)
diff --git a/convert.c b/convert.c
index c870817..ac04157 100644
--- a/convert.c
+++ b/convert.c
@@ -201,15 +201,21 @@ static char *crlf_to_worktree(const char *path, const char *src, unsigned long *
return buffer;
}
-static int filter_buffer(int fd, const char *src,
- unsigned long size, const char *cmd)
+struct filter_params {
+ const char *src;
+ unsigned long size;
+ const char *cmd;
+};
+
+static int filter_buffer(int fd, void *data)
{
/*
* Spawn cmd and feed the buffer contents through its stdin.
*/
struct child_process child_process;
+ struct filter_params *params = (struct filter_params *)data;
int write_err, status;
- const char *argv[] = { "sh", "-c", cmd, NULL };
+ const char *argv[] = { "sh", "-c", params->cmd, NULL };
memset(&child_process, 0, sizeof(child_process));
child_process.argv = argv;
@@ -217,17 +223,17 @@ static int filter_buffer(int fd, const char *src,
child_process.out = fd;
if (start_command(&child_process))
- return error("cannot fork to run external filter %s", cmd);
+ return error("cannot fork to run external filter %s", params->cmd);
- write_err = (write_in_full(child_process.in, src, size) < 0);
+ write_err = (write_in_full(child_process.in, params->src, params->size) < 0);
if (close(child_process.in))
write_err = 1;
if (write_err)
- error("cannot feed the input to external filter %s", cmd);
+ error("cannot feed the input to external filter %s", params->cmd);
status = finish_command(&child_process);
if (status)
- error("external filter %s failed %d", cmd, -status);
+ error("external filter %s failed %d", params->cmd, -status);
return (write_err || status);
}
@@ -241,42 +247,31 @@ static char *apply_filter(const char *path, const char *src,
* (child --> cmd) --> us
*/
const int SLOP = 4096;
- int pipe_feed[2];
- int status;
char *dst;
unsigned long dstsize, dstalloc;
- struct child_process child_process;
+ struct async async;
+ struct filter_params params;
if (!cmd)
return NULL;
- memset(&child_process, 0, sizeof(child_process));
-
- if (pipe(pipe_feed) < 0) {
- error("cannot create pipe to run external filter %s", cmd);
- return NULL;
- }
+ memset(&async, 0, sizeof(async));
+ async.proc = filter_buffer;
+ async.data = ¶ms;
+ params.src = src;
+ params.size = *sizep;
+ params.cmd = cmd;
fflush(NULL);
- child_process.pid = fork();
- if (child_process.pid < 0) {
- error("cannot fork to run external filter %s", cmd);
- close(pipe_feed[0]);
- close(pipe_feed[1]);
- return NULL;
- }
- if (!child_process.pid) {
- close(pipe_feed[0]);
- exit(filter_buffer(pipe_feed[1], src, *sizep, cmd));
- }
- close(pipe_feed[1]);
+ if (start_async(&async))
+ return NULL; /* error was already reported */
dstalloc = *sizep;
dst = xmalloc(dstalloc);
dstsize = 0;
while (1) {
- ssize_t numread = xread(pipe_feed[0], dst + dstsize,
+ ssize_t numread = xread(async.out, dst + dstsize,
dstalloc - dstsize);
if (numread <= 0) {
@@ -293,15 +288,14 @@ static char *apply_filter(const char *path, const char *src,
dst = xrealloc(dst, dstalloc);
}
}
- if (close(pipe_feed[0])) {
+ if (close(async.out)) {
error("read from external filter %s failed", cmd);
free(dst);
dst = NULL;
}
- status = finish_command(&child_process);
- if (status) {
- error("external filter %s failed %d", cmd, -status);
+ if (finish_async(&async)) {
+ error("external filter %s failed", cmd);
free(dst);
dst = NULL;
}
--
1.5.3.2.141.g48f10
^ permalink raw reply related
* Re: [PATCH] Add color to git-add--interactive diffs (Take 2: now without spurious line break!)
From: Johannes Schindelin @ 2007-10-14 17:15 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Tom Tobin, Git Mailing List
In-Reply-To: <EFADE863-FC59-4A50-B165-9D30D9648B97@wincent.com>
Hi,
On Sun, 14 Oct 2007, Wincent Colaiuta wrote:
> > +sub parse_color {
>
> You could simplify the manual escape sequence construction that you're
> doing here by using Term::ANSIColor like the other patches did. I see
> that git-send-email.perl uses that module too, so I guess depending on
> that module is ok.
Wrong. Depending on that module is not correct, you always have to wrap
it into an "if (<is_color>) {...}".
I use git add -i quite often, and I _never_ use git send-email. My guess
is that I am not alone with that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/6] add get_sha1_with_real_ref() returning full name of ref on demand
From: Johannes Schindelin @ 2007-10-14 17:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11923520852991-git-send-email-prohaska@zib.de>
Hi,
On Sun, 14 Oct 2007, Steffen Prohaska wrote:
> Deep inside get_sha1() the name of the requested ref is matched
> according to the rules documented in git-rev-parse. This patch
> introduces a function that returns the full name of the matched
> ref to the outside.
>
> For example 'master' is typically returned as 'refs/heads/master'.
>
> The new function can be used by "git rev-parse" to print the full
> name of the matched ref and can be used by "git send-pack" to expand
> a local ref to its full name.
I have not really studies your patch, but from your description it sounds
as if dwim_ref() does what you want.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Marius Storm-Olsen @ 2007-10-14 17:24 UTC (permalink / raw)
To: Christian Couder
Cc: Wincent Colaiuta, David Kastrup, René Scharfe, Junio Hamano,
Johannes Schindelin, git
In-Reply-To: <522E90CF-FC15-472F-B0A8-91C310CAF9BF@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
Wincent Colaiuta said the following on 14.10.2007 18:35:
> El 14/10/2007, a las 18:25, David Kastrup escribió:
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Christian Couder schrieb:
>>>> I choosed "dunno" because that was what Dscho suggested in
>>>> this thread:
>>>>
>>>> http://thread.gmane.org/gmane.comp.version-control.git/53584/
>>>> focus=53595
>>>>
>>>> It seems to me short and understandable at the same time.
>>>>
>>>> More meaningfull would be "untestable" or "cannottest" or
>>>> "canttest" but it's much longer, while "good" and "bad" are
>>>> short.
>>> Ugly? Neutral?
>> "Ugly" has a certain charm to it but would probably not translate
>> well. "Limbo" would be another such candidate, probably with
>> better translatability. But while some of those have some geeky
>> appeal, I really think something reasonably plain like
>> "undecided" would be better in the long run.
>
> "undecided" sounds good to me. It should be clear to non-native
> speakers of English (at least, clearer than "dunno").
What about just "unknown"?
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-14 17:25 UTC (permalink / raw)
To: Christian Couder; +Cc: Wincent Colaiuta, Junio Hamano, git
In-Reply-To: <200710141709.51579.chriscool@tuxfamily.org>
Hi,
On Sun, 14 Oct 2007, Christian Couder wrote:
> Le dimanche 14 octobre 2007, David Kastrup a ?crit :
> > Wincent Colaiuta <win@wincent.com> writes:
> > > El 14/10/2007, a las 14:28, Christian Couder escribi?:
> > >> Here is my bisect dunno patch series again.
> > >
> > > Good work on the series, Christian, but don't you think that
> > > "unknown" would sound a little bit better than "dunno"? For people
> > > who don't speak English as a second language "dunno" might not be
> > > immediately clear.
> >
> > "undecided"?
>
> I choosed "dunno" because that was what Dscho suggested in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/53584/focus=53595
>
> It seems to me short and understandable at the same time.
>
> More meaningfull would be "untestable" or "cannottest" or "canttest" but
> it's much longer, while "good" and "bad" are short.
I guess this discussion means that nobody has anything technical to argue
about. IOW your patch series is good...
;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git blame crashes with internal error
From: Johannes Schindelin @ 2007-10-14 17:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Andreas Ericsson, gitster, git
In-Reply-To: <20071014152327.GA24003@atjola.homenet>
Hi,
On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > Bj?rn Steinbrink wrote:
> >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current
> >> master and all of them crashed. A small shell script to reproduce the
> >> problem is attached.
> >
> > Manual bisect? Ugh. This *is* the century of the competent developer
> > tools, you know... ;-)
>
> Then, how do I search for a good version with git bisect if I only have
> the one data-point "master is bad"?
AFAIK Junio introduced the option to start with just a bad commit, and no
known "good" one.
Yep, just found it. Since v1.5.2-rc0~77^2(git-bisect: allow bisecting
with only one bad commit.) it is supported.
>From the commit message:
This allows you to say:
git bisect start
git bisect bad $bad
git bisect next
I don't know if it is in the documentation (I rarely read it), so if it is
missing, it would be nice if you could add the description there.
Ciao,
Dscho
^ permalink raw reply
* Re: git blame crashes with internal error
From: Alex Riesen @ 2007-10-14 17:33 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes Schindelin, Shawn O. Pearce,
Björn Steinbrink
In-Reply-To: <20071014163702.GA2776@steel.home>
Alex Riesen, Sun, Oct 14, 2007 18:37:02 +0200:
> Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:
> > Hi Junio,
> >
> > git blame just decided to crash on me, when I tried to use it while
> > resolving a merge conflict. Interesting is probably, that it crashes
> > when given the filename of a file that is not _directly_ affected by the
> > merge, but contains code that originates from a file that caused
> > conlicts.
> >
> > Error message is:
> > fatal: internal error: ce_mode is 0
> >
>
> It is not crashing. It is just not handling unexpected situation
> properly:
>
> $ testcase.sh
> ...
> Switched to branch "foo"
> CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.
> Automatic merge failed; fix conflicts and then commit the result.
> fatal: internal error: ce_mode is 0
> $ git ls-files --cached --stage
> 100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1 file1
> 100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3 file1
> 100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0 file2
>
> See? There is an unresolved merge.
>
> The question is, what's the problem...
>
FWIW, backtrace. I'm giving up for today. Anyone?
(gdb) bt
#0 0x080b6ac5 in die_builtin (err=0x80f3b92 "internal error: ce_mode is %o",
params=0xbfd91c34 "") at usage.c:24
#1 0x080b6b84 in die (err=0x80f3b92 "internal error: ce_mode is %o")
at usage.c:76
#2 0x080a3883 in ce_match_stat_basic (ce=0xb7f6a00c, st=0xbfd91cb8)
at read-cache.c:153
#3 0x080a398f in ie_match_stat (istate=0x81342e0, ce=0xb7f6a00c,
st=0xbfd91cb8, options=0) at read-cache.c:208
#4 0x080c87f3 in reuse_worktree_file (name=0x814c698 "file1",
sha1=0x814c668 "r\023\2378\2256y�\031��\223\214G\235s�{Y\230�024\b",
want_file=0) at diff.c:1499
#5 0x080c8a6f in diff_populate_filespec (s=0x814c668, size_only=1)
at diff.c:1565
#6 0x080d0ab2 in is_exact_match (src=0x814c668, dst=0x814ca20, contents_too=1)
at diffcore-rename.c:108
#7 0x080d13aa in diffcore_rename (options=0xbfd91edc) at diffcore-rename.c:335
#8 0x080ccaef in diffcore_std (options=0xbfd91edc) at diff.c:3120
#9 0x08054c33 in find_rename (sb=0xbfd921e8, parent=0x81377c0,
origin=0x814c5e0) at builtin-blame.c:427
#10 0x080563a3 in pass_blame (sb=0xbfd921e8, origin=0x814c5e0, opt=0)
at builtin-blame.c:1216
#11 0x08056d09 in assign_blame (sb=0xbfd921e8, revs=0xbfd92068, opt=0)
at builtin-blame.c:1501
#12 0x0805942a in cmd_blame (argc=2, argv=0xbfd92404, prefix=0x0)
at builtin-blame.c:2414
#13 0x0804b7d8 in run_command (p=0x80fa8d0, argc=2, argv=0xbfd92404)
at git.c:284
#14 0x0804b97a in handle_internal_command (argc=2, argv=0xbfd92404)
at git.c:398
#15 0x0804ba52 in main (argc=2, argv=0xbfd92404) at git.c:435
(gdb)
^ permalink raw reply
* Re: [PATCH - amended] git-gui: update Italian translation
From: Paolo Ciarrocchi @ 2007-10-14 17:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michele Ballabio, git, Johannes Schindelin
In-Reply-To: <20071012041535.GE27899@spearce.org>
On 10/12/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Michele Ballabio <barra_cuda@katamail.com> wrote:
Ciao Michele,
> > So here it is. (Sent as an attachment because I fear mangling, sorry).
No problem. I do apologize for being so late in the review but I've
been away from computers for a few days :-)
Michele I really like the work you did, FWIW it really deserve my:
Acked-by: Paolo Ciarrocchi <Paolo.Ciarrocchi@gmail.com>
The translation of "commit" you suggested is _really_ a lot better
then the translation mentioned in the tortoisesCVS repository:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Languages/Tortoise_it.po
> Thanks. I saw no further discussion on this thread so I have applied
> the attached patch as-is. It will be in my repo.or.cz tree in a
> couple of hours.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-14 17:48 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Christian Couder, Wincent Colaiuta, René Scharfe,
Junio Hamano, Johannes Schindelin, git
In-Reply-To: <471250BC.7070307@trolltech.com>
Marius Storm-Olsen <marius@trolltech.com> writes:
> Wincent Colaiuta said the following on 14.10.2007 18:35:
>
>> "undecided" sounds good to me. It should be clear to non-native
>> speakers of English (at least, clearer than "dunno").
>
> What about just "unknown"?
I tend to nitpick to the degree of silliness when my own suggestions
are concerned, but "unknown" sounds to me like the state _before_ the
test. If a person says he is "undecided" about something that means
that he _has_ thought about it already. "Undecidable" might bring
this distinction across more strongly, but it is a more complicated
word and it insinuates that it is _impossible_ to come to a decision
regardless of the spent effort.
"unknown" clearly is much better than "dunno" though even if my own
favorite would be "undecided".
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git blame crashes with internal error
From: Johannes Schindelin @ 2007-10-14 17:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Björn Steinbrink, gitster, git
In-Reply-To: <20071014163702.GA2776@steel.home>
Hi,
On Sun, 14 Oct 2007, Alex Riesen wrote:
> Bj?rn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:
> >
> > git blame just decided to crash on me, when I tried to use it while
> > resolving a merge conflict. Interesting is probably, that it crashes
> > when given the filename of a file that is not _directly_ affected by
> > the merge, but contains code that originates from a file that caused
> > conlicts.
> >
> > Error message is: fatal: internal error: ce_mode is 0
>
> It is not crashing. It is just not handling unexpected situation
> properly:
>
> $ testcase.sh
> ...
> Switched to branch "foo"
> CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.
> Automatic merge failed; fix conflicts and then commit the result.
> fatal: internal error: ce_mode is 0
> $ git ls-files --cached --stage
> 100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1 file1
> 100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3 file1
> 100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0 file2
>
> See? There is an unresolved merge.
I _think_ that what blame does here is correct. It wants to handle the
rename case, and because of the conflicts, it cannot determine the
renames.
The proper thing to do now would be
git blame HEAD file2
since you want to exclude the working tree from the blaming.
I agree that the error message is not really helping here, though. Since
we are not really libified, I do not see an easy way to help here, either,
short of git-blame checking for unmerged entries.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add color to git-add--interactive diffs (Take 2: now without spurious line break!)
From: Andreas Ericsson @ 2007-10-14 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wincent Colaiuta, Tom Tobin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710141814100.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Wincent Colaiuta wrote:
>
>>> +sub parse_color {
>> You could simplify the manual escape sequence construction that you're
>> doing here by using Term::ANSIColor like the other patches did. I see
>> that git-send-email.perl uses that module too, so I guess depending on
>> that module is ok.
>
> Wrong. Depending on that module is not correct, you always have to wrap
> it into an "if (<is_color>) {...}".
>
> I use git add -i quite often, and I _never_ use git send-email. My guess
> is that I am not alone with that.
>
Not by a longshot, no. Personally I find git-send-email so tricky to use I've
rolled my own sender. I circulated it on the list a year or so back, but it's
not nearly so feature-full as git-send-email, so it never got much of an
audience.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Johannes Schindelin @ 2007-10-14 18:02 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Eric Wong, git
In-Reply-To: <Pine.LNX.4.64.0710141751530.25221@racer.site>
Hi,
On Sun, 14 Oct 2007, Johannes Schindelin wrote:
> When there is an option "--amend", the option parser now recognizes
> "--am" for that option, provided that there is no other option beginning
> with "--am".
And an amend for ultra-abbreviated options (as you noticed on IRC):
diff --git a/parse-options.c b/parse-options.c
index afc6c89..acabb98 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -137,6 +137,11 @@ is_abbreviated:
abbrev_flags = flags;
continue;
}
+ /* negated and abbreviated very much? */
+ if (!prefixcmp("no-", arg)) {
+ flags |= OPT_UNSET;
+ goto is_abbreviated;
+ }
/* negated? */
if (strncmp(arg, "no-", 3))
continue;
^ permalink raw reply related
* Re: Switching from CVS to GIT
From: Marco Costalba @ 2007-10-14 18:06 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list, Eli Zaretskii, Make Windows
In-Reply-To: <1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr>
On 10/14/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>
> Is it possible to use one of
> the various GUIs (git-gui, gitk, qgit) on Windows without requiring a
> POSIXish shell etc.?
>
qgit-2.0 works natively under Windows
http://sourceforge.net/project/showfiles.php?group_id=139897
Check the README for how to install.
Marco
^ permalink raw reply
* Re: [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Pierre Habouzit @ 2007-10-14 18:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, git
In-Reply-To: <Pine.LNX.4.64.0710141901450.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On Sun, Oct 14, 2007 at 06:02:33PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Johannes Schindelin wrote:
>
> > When there is an option "--amend", the option parser now recognizes
> > "--am" for that option, provided that there is no other option beginning
> > with "--am".
>
> And an amend for ultra-abbreviated options (as you noticed on IRC):
>
> diff --git a/parse-options.c b/parse-options.c
> index afc6c89..acabb98 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -137,6 +137,11 @@ is_abbreviated:
> abbrev_flags = flags;
> continue;
> }
> + /* negated and abbreviated very much? */
> + if (!prefixcmp("no-", arg)) {
> + flags |= OPT_UNSET;
> + goto is_abbreviated;
> + }
> /* negated? */
> if (strncmp(arg, "no-", 3))
> continue;
squashed on top on the previous, and pushed to my ph/parseopt branch.
--
·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 User's Survey 2007 unfinished summary continued
From: Steven Grimm @ 2007-10-14 18:12 UTC (permalink / raw)
To: Reece Dunn
Cc: Shawn O. Pearce, Linus Torvalds, Johannes Schindelin,
J. Bruce Fields, Jakub Narebski, git
In-Reply-To: <3f4fd2640710140320h5c1e1f7gf9f43a626aaa6897@mail.gmail.com>
Reece Dunn wrote:
> The core plumbing in git is solid. The porcelain, with the 1.5 series,
> makes git simpler to use from the command line. Now, the GUI available
> for git is seriously lacking.
>
I'm not sure I agree with that. Here's the section on git from the
"Comparison with other systems" part of the Mercurial book. I'll
reproduce it in its entirety here and add my own comments about each
paragraph.
> Git is a distributed revision control tool that was developed for
managing the
> Linux kernel source tree. Like Mercurial, its early design was
somewhat influenced
> by Monotone.
No argument there.
> Git has an overwhelming command set, with version 1.5.0 providing 139
> individual commands. It has a reputation for being difficult to
learn. It does not have
> a user manual, only documentation for individual commands.
The part about the user manual is bunk (and was bunk in version 1.5.0,
IIRC, so I'm not sure where he gets that.) But the first part of that is
the key here. I admit that's even bitten me from time to time. I
couldn't remember the name of the "git-instaweb" command just yesterday;
doing "ls /usr/local/bin/git-*" was, I'd have to agree, pretty overwhelming.
We could probably solve that by tucking the plumbing commands away in a
lib or libexec directory and only exposing the porcelain commands in the
directory the end user is likely to look at.
But that's just an aspect of a more general fact: it's hard to use git
without getting exposed to the plumbing at least a little. Another
example is the manpages: try to look up the commonly-used options to
"git diff" (porcelain) and you will be forced to learn about "git
rev-parse" (plumbing).
The point is, though, that this is a valid complaint about git's UI that
has nothing to do with GUIs.
> In terms of performance, git is extremely fast. There are several
common cases
> in which it is faster than Mercurial, at least on Linux. However, its
performance
> on (and general support for) Windows is, at the time of writing, far
behind that of
> Mercurial.
A fair statement, though of course that's been improving by leaps and
bounds of late and hopefully will soon be an outdated argument. The
Windows user experience has been subpar historically.
> While a Mercurial repository needs no maintenance, a Git repository
requires frequent
> manual “repacks” of its metadata. Without these, performance
degrades, while space
> usage grows rapidly. A server that contains many Git repositories
that are not rigorously
> and frequently repacked will become heavily disk-bound during
backups, and there
> have been instances of daily backups taking far longer than 24 hours
as a result.
> A freshly packed Git repository is slightly smaller than a Mercurial
repository, but an
> unpacked repository is several orders of magnitude larger.
This was true at the time the hg book was written. Now that we have the
auto-packing code, hopefully it will be a moot point. So that's one "fix
the UI" complaint that has been addressed; whether *successfully* or
not, time will tell. But hg definitely had a user experience advantage
here until very recently.
> The core of Git is written in C. Many Git commands are implemented as
shell or Perl
> scripts, and the quality of these scripts varies widely. I have
encountered a number of
> instances where scripts charged along blindly in the presence of
errors that should have
> been fatal.
No doubt this is true as well. Obviously the C-ification process will
take care of a lot of this, though of course one can charge along
blindly in the presence of errors in any language (including, shock of
shocks given the implication here, Python.) To the extent we can find
places where this is still true, obviously they should be fixed. I
wonder if anyone knows the author of the book well enough to ferret some
specifics out of him toward that end.
Now, about hg vs. git in general. I actually spent some time this
weekend coming up to speed on hg basics just to see what all the UI fuss
was about. As far as I can see it is about a wash all told; some things
are easier in git and some in hg. However, here's my speculation about
why people might claim hg is easier. I see three things:
Multiple branches per repo. Mercurial allows them, but you won't find
them mentioned anywhere in any of the beginner tutorials. They encourage
people to use a "one repo per branch" model. Having gotten used to git's
branching model, you'd have to pry that feature out of my cold, dead
fingers, but it's fundamentally much easier to understand a model of "if
you want to make two unrelated changes to your code, just make two
copies of the source tree." It's possible git's introductory
documentation should delay talking about "git branch" until later, and
start off talking about how to work with one (checked out) branch per repo.
Update to a dirty working copy. I think there's a tendency in these
parts to vastly underestimate the importance of being able to pull down
updates from a master repository while you're in the middle of
development. Mercurial's equivalent to bare "git pull", namely "hg pull"
followed by "hg update", works fine if you have edits in your working
copy; if there are conflicting changes, it pops you into a conflict
resolution UI (or adds conflict markers, depending on your settings) and
you continue on your merry way after resolving everything. This workflow
is really common, especially in corporate settings where there's very
fine-grained collaboration going on during initial development (a huge
difference from the open-source world where most of the time it's just
one person doing an initial prototype.) Right now working this way is a
pain in git. Less so now that we have "git stash", but it could still be
much, much smoother.
Verbosity. IMO Mercurial swings too far in this direction, but in
general it's either completely silent or very terse in its output. There
is never, as far as I can see, any low-level diagnostic information spit
out to the user unless an hg command is run with a "verbose" option.
Here's "hg pull; hg update", for example (and "pull" is one of hg's
chattier commands):
pulling from ../child1
searching for changes
adding changesets
adding manifests
adding file changes
added 8 changesets with 8 changes to 3 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
Compare with the equivalent "git pull" and put yourself in the shoes of
a user who is running that command for the first time:
remote: Generating pack...
remote: Counting objects: 9
remote: Done counting 1118 objects.
Result has 832 objects.
remote: Deltifying 822 objects...
remote: 100% (822/822) done
Indexing 832 objects...
remote: Total 832 (delta 668), reused 0 (delta 0)
100% (832/832) done
Resolving 668 deltas...
100% (668/668) done
258 objects were added to complete this thin pack.
* refs/remotes/origin/session-fix: fast forward to branch 'session-fix'
of ssh://devrs005/~/www
old..new: 3de27db..a3d44c1
Already up-to-date.
So anyway, there are a few specifics. That's based on just a bit of
playing around with hg; maybe the differences go deeper than this, but I
think there isn't a huge usability gap between the two systems any more.
-Steve
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-14 18:20 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list, Eli Zaretskii, Make Windows
In-Reply-To: <1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr>
Hi,
On Sun, 14 Oct 2007, Benoit SIGOURE wrote:
> Context: GNU make seems to be willing to switch from CVS to ...
> something else.
>
> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
>
> > [...] the big thing no one else seems to have addressed much in other
> > discussions I've seen is portability. It LOOKS like there are native
> > ports of GIT to MINGW, but I have no idea how complete and usable they
> > are. If someone who has a Windows system could look into that it
> > would be a big help.
There is msysGit. This project is nearing to its first beta, being
self-hosted since mid-August IIRC.
It is a port of Git to MinGW, using parts of MSys as long as we have
dependencies on bash and perl.
I have no doubt that we'll manage to finish version 0.3 of the installer
this week, still not decided if it is still alpha or already beta.
There are some issues with using msysGit, none of them really serious, but
you better be ready to ask questions on this list or #git in case
something crops up. msysGit is young.
Having said that, IMHO msysGit is already quite usable, and should be
pretty stable within a few weeks (if it is not already).
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-14 18:27 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list, Eli Zaretskii, Make Windows
In-Reply-To: <1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr>
Benoit SIGOURE wrote:
> Context: GNU make seems to be willing to switch from CVS to ...
> something else.
>
> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
>
>> [...] the big thing no one else seems to have addressed much in
>> other discussions I've seen is portability. It LOOKS like there are
>> native ports of GIT to MINGW, but I have no idea how complete and usable
>> they are. If someone who has a Windows system could look into that it
>> would be a big help.
>
> I think the best thing to do is to ask directly on the Git ML.
>
> Someone already pointed out that he'd like to use Git on Windows but
> doesn't want to install either Cygwin or MSYS. Is this possible, or
> will it be possible in the near future?
It is sort of possible. Without cygwin he'll be in the black for the few
features that are still implemented as shell-scripts, but perhaps he/she
will then be inclined to help us migrate those scripts to C builtins.
> Is it possible to use one of
> the various GUIs (git-gui, gitk, qgit) on Windows without requiring a
> POSIXish shell etc.?
>
qgit is possible to use natively, if one installs the qgit4 libraries for
windows, but it's more of a viewer than an action gui. git-gui and gitk
are usable if you have the windows TCL port. I haven't tried it, but
there are installers available, so testing it out (with all dependencies)
shouldn't take too long.
> When will the librarification of Git be finished?
When someone gets around to doing it ;-)
For a real answer, I'll have to defer to others. Everything works to my
satisfaction where I'm using it, so I'm not very inclined to fiddle with
it and risk breaking things.
> (if Git is available
> as a library, and if this library works on Windows, it will greatly help
> truly native Windows ports).
>
Yup. I believe the primary reason for libification is to easier support
both porting and fully-fledged gui's.
> Not that I like Windows in any way, right, but it's legitimate for
> people working on Windows ports of various software to be willing to
> have a truly native port of Git for Windows.
>
Naturally. Amazingly few of those stuck with windows have so far
volunteered for helping out though, and since many of us on this list
don't even have a windows system for testing, it's kinda slow going :-/
I'd imagine getting in touch with Dscho to get a list of what's needed,
or reading the biweekly msys.git herald on this list, is the best way
of finding out the porting project's current priorities.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-14 18:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Benoit SIGOURE, git list, Eli Zaretskii, Make Windows
In-Reply-To: <47125F74.9050600@op5.se>
Hi,
On Sun, 14 Oct 2007, Andreas Ericsson wrote:
> Benoit SIGOURE wrote:
> > Context: GNU make seems to be willing to switch from CVS to ... something
> > else.
> >
> > On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
> >
> > > [...] the big thing no one else seems to have addressed much in
> > > other discussions I've seen is portability. It LOOKS like there are
> > > native ports of GIT to MINGW, but I have no idea how complete and usable
> > > they are. If someone who has a Windows system could look into that it
> > > would be a big help.
> >
> > I think the best thing to do is to ask directly on the Git ML.
> >
> > Someone already pointed out that he'd like to use Git on Windows but
> > doesn't want to install either Cygwin or MSYS. Is this possible, or
> > will it be possible in the near future?
>
> It is sort of possible. Without cygwin he'll be in the black for the few
> features that are still implemented as shell-scripts, but perhaps he/she
> will then be inclined to help us migrate those scripts to C builtins.
Umm. There are quite a few shell scripts still _necessary_ to run git:
git-commit, git-fetch and git-merge being the most prominent ones. The
first two are in the process of being rewritten _right_ _now_, but no
official git release has them yet.
And I have to disagree strongly with the "black": In msysGit (which brings
its own minimal version of MSys), it is very smooth.
> > Is it possible to use one of the various GUIs (git-gui, gitk, qgit)
> > on Windows without requiring a POSIXish shell etc.?
> >
>
> qgit is possible to use natively, if one installs the qgit4 libraries
> for windows, but it's more of a viewer than an action gui. git-gui and
> gitk are usable if you have the windows TCL port. I haven't tried it,
> but there are installers available, so testing it out (with all
> dependencies) shouldn't take too long.
FWIW msysGit comes with Tcl. You can run git gui and gitk without any
hassles.
> > When will the librarification of Git be finished?
>
> When someone gets around to doing it ;-)
There has been a GSoC project, and it has a nice small API which can be
called from Python, for example.
Funnily enough, the first user is qgit as far as I know, which is written
in C++...
> > (if Git is available as a library, and if this library works on
> > Windows, it will greatly help truly native Windows ports).
>
> Yup. I believe the primary reason for libification is to easier support
> both porting and fully-fledged gui's.
Why?
I do not see any reason why libification helps the user experience on
Windows.
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-14 18:40 UTC (permalink / raw)
To: Steven Grimm
Cc: Reece Dunn, Shawn O. Pearce, Linus Torvalds, Johannes Schindelin,
Jakub Narebski, git
In-Reply-To: <47125BF7.2070503@midwinter.com>
On Sun, Oct 14, 2007 at 11:12:07AM -0700, Steven Grimm wrote:
> But that's just an aspect of a more general fact: it's hard to use git
> without getting exposed to the plumbing at least a little. Another example
> is the manpages: try to look up the commonly-used options to "git diff"
> (porcelain) and you will be forced to learn about "git rev-parse"
> (plumbing).
As "plumbing" goes, "git rev-parse" isn't that bad, and the reference
here (to the "SPECIFYING REVISIONS" section) strikes me as reasonable.
We could factor out the common documentation into a separate (hopefully
more user-friendly) manpage about specifying revisions, I guess, and
refer to it everywhere instead of git-rev-parse. I don't know--any
other ideas?
> It's possible git's introductory documentation should delay talking
> about "git branch" until later, and start off talking about how to work
> with one (checked out) branch per repo.
One frequent use case is the case of a tester that wants to try out a
bugfix in some topic branch. You want to tell them: "please test the
fix-that-bug branch in git://myproject.org/~me/repo.git". They need to
get that checked out somehow. And they should be able to do it without
re-cloning every time.
That's one motivation, among others, for including git-branch (and
git-remote) very early.
Though actually the quickest way to checkout an arbitrary revision is
with detached heads, and that doesn't require learning git-branch right
away. I've tried rewriting the user-manual start that way but wasn't
happy with the result and didn't get too far. (See
git://linux-nfs.org/~bfields/git.git docwork-detached.)
> Update to a dirty working copy. I think there's a tendency in these parts
> to vastly underestimate the importance of being able to pull down updates
> from a master repository while you're in the middle of development.
> Mercurial's equivalent to bare "git pull", namely "hg pull" followed by "hg
> update", works fine if you have edits in your working copy; if there are
> conflicting changes, it pops you into a conflict resolution UI (or adds
> conflict markers, depending on your settings) and you continue on your
> merry way after resolving everything. This workflow is really common,
> especially in corporate settings where there's very fine-grained
> collaboration going on during initial development (a huge difference from
> the open-source world where most of the time it's just one person doing an
> initial prototype.) Right now working this way is a pain in git. Less so
> now that we have "git stash", but it could still be much, much smoother.
I'm lost--how is "hg pull" different from "git pull" in this respect?
> Verbosity. IMO Mercurial swings too far in this direction, but in general
> it's either completely silent or very terse in its output.
Yes, there's a lot of low-hanging fruit here for someone that's
interested in streamlining the default git command output. The
challenge is to get it a little terser while still being helpful (and
preserving progress meters, and not obscuring what's going on any more
than necessary).
--b.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-14 19:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, git list, Eli Zaretskii, Make Windows
In-Reply-To: <Pine.LNX.4.64.0710141934310.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Andreas Ericsson wrote:
>
>> Benoit SIGOURE wrote:
>>> Context: GNU make seems to be willing to switch from CVS to ... something
>>> else.
>>>
>>> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
>>>
>>>> [...] the big thing no one else seems to have addressed much in
>>>> other discussions I've seen is portability. It LOOKS like there are
>>>> native ports of GIT to MINGW, but I have no idea how complete and usable
>>>> they are. If someone who has a Windows system could look into that it
>>>> would be a big help.
>>> I think the best thing to do is to ask directly on the Git ML.
>>>
>>> Someone already pointed out that he'd like to use Git on Windows but
>>> doesn't want to install either Cygwin or MSYS. Is this possible, or
>>> will it be possible in the near future?
>> It is sort of possible. Without cygwin he'll be in the black for the few
>> features that are still implemented as shell-scripts, but perhaps he/she
>> will then be inclined to help us migrate those scripts to C builtins.
>
> Umm. There are quite a few shell scripts still _necessary_ to run git:
> git-commit, git-fetch and git-merge being the most prominent ones. The
> first two are in the process of being rewritten _right_ _now_, but no
> official git release has them yet.
>
Ah, right. I think of "accepted into git.git" as being released.
> And I have to disagree strongly with the "black": In msysGit (which brings
> its own minimal version of MSys), it is very smooth.
>
Oh? I didn't know that. Windows and its unixifying toolboxes is unknown
territory to me, as I happily spend all my time on various unices.
>>> Is it possible to use one of the various GUIs (git-gui, gitk, qgit)
>>> on Windows without requiring a POSIXish shell etc.?
>>>
>> qgit is possible to use natively, if one installs the qgit4 libraries
>> for windows, but it's more of a viewer than an action gui. git-gui and
>> gitk are usable if you have the windows TCL port. I haven't tried it,
>> but there are installers available, so testing it out (with all
>> dependencies) shouldn't take too long.
>
> FWIW msysGit comes with Tcl. You can run git gui and gitk without any
> hassles.
>
Yes, my phrasing there was a bit obscure. I meant that all dependencies
are installed by the installer package.
>>> (if Git is available as a library, and if this library works on
>>> Windows, it will greatly help truly native Windows ports).
>> Yup. I believe the primary reason for libification is to easier support
>> both porting and fully-fledged gui's.
>
> Why?
>
> I do not see any reason why libification helps the user experience on
> Windows.
>
I was under the impression that the windows port suffers from Windows'
lack of a proper fork() and friends and that a proper library would
help solving those problems. Perhaps I was misinformed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Steven Grimm @ 2007-10-14 19:25 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Reece Dunn, Shawn O. Pearce, Linus Torvalds, Johannes Schindelin,
Jakub Narebski, git
In-Reply-To: <20071014184050.GB31260@fieldses.org>
J. Bruce Fields wrote:
> I'm lost--how is "hg pull" different from "git pull" in this respect?
>
(Pedantry alert: "hg pull" is equivalent to "git fetch" and doesn't
update the working copy. I'll talk here about the "hg pull; hg update"
pair which seems to be standard procedure in hg land.)
Here's a simple example in each system to demonstrate the difference.
---
mkdir parent
cd parent
git init
echo 'my baloney has a first name' > song.txt
echo "it's o-s-c-a-r" >> song.txt
echo 'my baloney has a last name' >> song.txt
git add song.txt
git commit -m "test file"
cd ..
git clone parent child
cd parent
echo "it's m-a-y-e-r" >> song.txt
git commit -a -m "another line in the song"
cd ../child
perl -pi -e 's/first name/given name/' song.txt
git pull
---
Result: "fatal: Entry 'song.txt not uptodate. Cannot merge."
---
mkdir hgparent
cd hgparent
hg init
echo 'my baloney has a first name' > song.txt
echo "it's o-s-c-a-r" >> song.txt
echo 'my baloney has a last name' >> song.txt
hg add song.txt
hg commit -m "test file"
cd ..
hg clone hgparent hgchild
cd hgparent
echo "it's m-a-y-e-r" >> song.txt
hg commit -m "another line in the song"
cd ../hgchild
perl -pi -e 's/first name/given name/' song.txt
hg pull
hg update
---
Result: "0 files updated, 1 files merged, 0 files removed, 0 files
unresolved" and the file contains the change from the parent plus the
change from the child, with the latter still an uncommitted edit that
shows up in "hg diff".
-Steve
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Nicolas Pitre @ 2007-10-14 19:44 UTC (permalink / raw)
To: Steven Grimm
Cc: Reece Dunn, Shawn O. Pearce, Linus Torvalds, Johannes Schindelin,
J. Bruce Fields, Jakub Narebski, git
In-Reply-To: <47125BF7.2070503@midwinter.com>
On Sun, 14 Oct 2007, Steven Grimm wrote:
> Verbosity. IMO Mercurial swings too far in this direction, but in general it's
> either completely silent or very terse in its output. There is never, as far
> as I can see, any low-level diagnostic information spit out to the user unless
> an hg command is run with a "verbose" option. Here's "hg pull; hg update", for
> example (and "pull" is one of hg's chattier commands):
>
> pulling from ../child1
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 8 changesets with 8 changes to 3 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> 3 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> Compare with the equivalent "git pull" and put yourself in the shoes of a user
> who is running that command for the first time:
BTW I have patches here reworking the progress code for a more compact
display which should mitigate this issue quite a bit.
Nicolas
^ 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