* Re: obnoxious CLI complaints
From: Linus Torvalds @ 2009-09-11 22:16 UTC (permalink / raw)
To: René Scharfe; +Cc: Jakub Narebski, Brendan Miller, git
In-Reply-To: <4AAAC8CE.8020302@lsrfire.ath.cx>
On Sat, 12 Sep 2009, René Scharfe wrote:
>
> But what has bugged me since I added zip support is this result:
>
> # git v1.6.5-rc0
> $ time git archive --format=zip -6 v2.6.31 >/dev/null
>
> real 0m16.471s
> user 0m16.340s
> sys 0m0.128s
>
> I'd have expected this to be the slowest case, because it's compressing
> all files separately, i.e. it needs to create and flush the compression
> context lots of times instead of only once as in the two cases above.
Oh no, I think it's easily explained.
Compressing many small files really is often cheaper than compressing one
large one.
With lots of small files, you end up being very limited in the
search-space, so the compression decisions get simpler. Compression in
general is not O(n), it's some non-linear factor, often something like
O(n**2).
Of course, all compression libraries have an upper bound on the
non-linearity (often expressed as a "window size"), so a particular
compression algorithm may end up being close to O(n) (with a huge
constant). But that upper bound will only kick in for large files, small
files that fit entirely into the compression window will still see the
underlying O(n**2) or whatever.
But I have no actual numbers to back up the above blathering. But feel
free to try to compress 10 small files and compare it to compressing one
file that is as big as the sum. I bet you'll see it.
Linus
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Daniel Barkalow @ 2009-09-11 22:47 UTC (permalink / raw)
To: Jeff King; +Cc: Johan Sørensen, Aloisio, git, support
In-Reply-To: <20090911162013.GA10939@coredump.intra.peff.net>
On Fri, 11 Sep 2009, Jeff King wrote:
> On Fri, Sep 11, 2009 at 12:05:10PM -0400, Jeff King wrote:
>
> > Ah. I have a theory. If I do a clone of git://gitorious.org/qt/qt.git,
> > the counting/compressing stages take a long time (I timed it at 1m40
> > before it actually sends any data). And looking at upload-pack.c, we
> > leave the 30-second alarm set while creating the pack. Meaning we die 30
> > seconds into creating the pack.
> >
> > When progress is being displayed, however, the progress timer actually
> > uses SIGALRM, as well. So we are constantly resetting the timer and it
> > never goes off.
>
> Hmm. Actually, this is not quite right. It looks like we call out to
> pack-objects as an external program, so there is no conflict with the
> signal. And we do proxy the output of pack-objects, which will keep our
> timer resetting every time we see a chunk of output. But pack-objects
> produces no output during the deltification phase, unless progress is
> turned on. So we still hit our timeout in upload-pack during that
> phase.
>
> So our options are:
>
> 1. Turn off the timer during deltification, which could mean that it
> would potentially go forever. But it's not controlled by the user.
> I think the 'timeout' feature is really about the client just
> opening the connection and sitting.
>
> 2. Keep progress on during deltification, but just throw it away
> instead of relaying it if no-progress is in effect.
>
> 3. Accept that hitting the timeout during deltification _should_ cause
> it to die. In that case, then the case with progress is wrong, and
> we should stop resetting the timer just because we got some
> progress output from pack-objects. But this may be redefining the
> intent of --timeout. I don't know what the original intent was, or
> what users of the feature are expecting.
You don't remember October 2005? HPA introduced it in 960decc, which has a
pretty good explanation: we doesn't want to get DoS'd if clients just send
SYNs. So it's supposed to time out only if we spend that long waiting
for a protocol item from the client.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] completion: Replace config --list with --get-regexp
From: Todd Zullinger @ 2009-09-11 23:23 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, james bardin, git, Junio C Hamano
In-Reply-To: <20090911150934.GB977@coredump.intra.peff.net>
James Bardin noted that the completion spewed warnings when no git
config file is present. This is likely a bug to be fixed in git config,
but it's also a good excuse to simplify the completion code by using the
--get-regexp option as Jeff King pointed out.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
Jeff King wrote:
> On Fri, Sep 11, 2009 at 07:36:51AM -0700, Shawn O. Pearce wrote:
>
>>> instead of just using "git config --get-regexp 'remote\..*\.url'", which
>>> would be slightly more efficient, and also doesn't have this bug. ;)
>>
>> F'king oversight. You are right, this should be --get-regexp.
>> There isn't a reason here, probably other than "I forgot about
>> --get-regexp when I wrote the original code".
>
> OK. I will leave a bash-completion patch for you (or somebody else
> interested) as I don't use it myself.
Something like this perhaps? Perhaps the commit message could use
adjustment to reference your fix for 'config --list'?
contrib/completion/git-completion.bash | 30 +++++++++---------------------
1 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bf688e1..d668fc9 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -318,13 +318,9 @@ __git_remotes ()
echo ${i#$d/remotes/}
done
[ "$ngoff" ] && shopt -u nullglob
- for i in $(git --git-dir="$d" config --list); do
- case "$i" in
- remote.*.url=*)
- i="${i#remote.}"
- echo "${i/.url=*/}"
- ;;
- esac
+ for i in $(git --git-dir="$d" config --get-regexp 'remote\..*\.url' 2>/dev/null); do
+ i="${i#remote.}"
+ echo "${i/.url*/}"
done
}
@@ -605,13 +601,9 @@ __git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
local i IFS=$'\n'
- for i in $(git --git-dir="$(__gitdir)" config --list); do
- case "$i" in
- alias.*)
- i="${i#alias.}"
- echo "${i/=*/}"
- ;;
- esac
+ for i in $(git --git-dir="$(__gitdir)" config --get-regexp "alias\..*" 2>/dev/null); do
+ i="${i#alias.}"
+ echo "${i/ */}"
done
}
@@ -1769,13 +1761,9 @@ _git_remote ()
;;
update)
local i c='' IFS=$'\n'
- for i in $(git --git-dir="$(__gitdir)" config --list); do
- case "$i" in
- remotes.*)
- i="${i#remotes.}"
- c="$c ${i/=*/}"
- ;;
- esac
+ for i in $(git --git-dir="$(__gitdir)" config --get-regexp "remotes\..*" 2>/dev/null); do
+ i="${i#remotes.}"
+ c="$c ${i/ */}"
done
__gitcomp "$c"
;;
--
1.6.4.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That men do not learn very much from the lessons of history is the
most important of all the lessons of history.
-- Aldous Huxley Collected Essays, 1959
^ permalink raw reply related
* Re: [PATCH] send-email: confirm on empty mail subjects
From: Junio C Hamano @ 2009-09-11 23:27 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <1249490994-23455-1-git-send-email-jengelh@medozas.de>
Jan Engelhardt <jengelh@medozas.de> writes:
> When the user forgot to enter a subject in a compose session,
> send-email will now inquire whether this is really intended, similar
> to what the Alpine MUA does when a subject is absent.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
> ---
> git-send-email.perl | 25 ++++++++++++++++++++-----
> 1 files changed, 20 insertions(+), 5 deletions(-)
We have had this for quite a long time but I have two niggling worries,
one minor, another one showstopper from maintainability point of view.
- With --confirm=never the program still seems to talk with the terminal.
I think with --confirm=neber we should not ask but just fail.
- This does not hook into the confirmation framework the program already
has, and does not have any way to turn it off.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index d508f83..7d56fba 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -553,11 +553,26 @@ EOT
> }
> close(C);
>
> - if ($annotate) {
> - do_edit($compose_filename, @files);
> - } else {
> - do_edit($compose_filename);
> - }
> + my $re_edit = 0;
> + do {
> + if ($annotate) {
> + do_edit($compose_filename, @files);
> + } else {
> + do_edit($compose_filename);
> + }
> +
> + open(C, "<", $compose_filename) ||
> + die "Failed to open $compose_filename: $!";
> + if (grep(/^Subject:\s*$/i, <C>)) {
> + my $r = ask("No Subject, send anyway? ".
> + "([y]es|[n]o|[e]dit again): ",
> + valid_re => qr/^[yne]/i,
> + default => "n");
> + $re_edit = lc(substr($r, 0, 1)) eq "e";
> + exit(0) if lc(substr($r, 0, 1)) eq "n";
> + }
> + close C;
> + } while ($re_edit);
>
> open(C2,">",$compose_filename . ".final")
> or die "Failed to open $compose_filename.final : " . $!;
> --
> 1.6.4
^ permalink raw reply
* Re: previously committed file untracked prevent checking out an old tag/branch
From: Junio C Hamano @ 2009-09-12 0:06 UTC (permalink / raw)
To: Daniele Segato; +Cc: git
In-Reply-To: <9accb4400909110426v2a42086ema318167e94b2cbc1@mail.gmail.com>
Daniele Segato <daniele.bilug@gmail.com> writes:
> I only can think of doing a backup of my build.properties, delete it
> and check out the tag or I just delete it and rebuild
> it from the template later.
That is the right approach, but you could automate it further.
The project I help at work has a similar set-up. The Makefile defines a
plain vanilla set of configuration via the Make variables, and they can be
overriden by including ./config.mk. The master branch does not have the
file tracked, but ./config.mk-sample file is tracked and the developers
can use it as a template.
The developers can have an untracked (from the project's point of view)
subdirectory, local/. with local/myconfig.mk file. "local" is in fact a
full fledged git repository with local/.git and changes to myconfig.mk can
be tracked there. It is not (and should not be) a subproject.
Because what appear in the sample config.mk-sample are a bunch of Make
variable definitions, and in Make, later definition trumps the earlier
ones, So the developers can do:
$ cat config.mk-sample local/myconfig.mk >config.mk
$ make
The first step can be in the Makefile; the above command line is for
illustration.
For branches that are used for specific customer release, we track their
config.mk file. That means the developer would lose config.mk file if he
does this:
$ git checkout master
$ cat config.mk-sample local/myconfig.mk >config.mk
$ make
... do the usual work of developing and testing ...
$ git checkout customer ;# may fail due to config.mk
$ rm -f config.mk ;# so get rid of it
$ git checkout customer ;# now it is ok
$ make ;# for real release
... or perhaps to diagnose the issue at customer site ...
$ edit config.mk ;# minimally adjust for testing
$ make
$ test
... done, and go back to the regular programming ...
$ git checkout config.mk ;# get rid of local changes
$ git checkout master
But because the real configuration is tracked in local/.git, there is no
information lossage.
The generic config.mk _could_ be written to include local/myconfig.mk if
exists, in order to help debugging or testing the customer branch (then
there is no need for "edit config.mk for testing and then revert" steps),
but we chose not to do so, as it risks the release/build engineer to
forget that he has funny customization in his local/myconfig.mk file and
screwing up the release by inadvertently including the customization.
HTH ;-)
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Junio C Hamano @ 2009-09-12 0:11 UTC (permalink / raw)
To: Johan Herland
Cc: git, Johannes.Schindelin, trast, tavestbo, git, chriscool,
spearce
In-Reply-To: <1252376822-6138-1-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Yet another iteration of the 'git notes' feature. Rebased on top of 'next':
By the way I didn't pick this up as it did not apply to any of my
branches.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Junio C Hamano @ 2009-09-12 0:33 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Sverre Rabbelier, Jeff King, Johannes Schindelin,
Daniel Barkalow, Jan Engelhardt, Johan Herland, Linus Torvalds
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
This is an abbreviated preview of issue #03 for this month; the message
primarily covers potential 1.6.5 material and omits topics without much
urgency for the purpose of pushing 1.6.5-rc1 out.
--------------------------------------------------
[New Topics]
* jc/merge-saner-messages (2009-09-07) 1 commit
(merged to 'next' on 2009-09-11 at 4efab98)
+ merge-recursive: give less scary messages when merge did not start
I think this should be safe for 1.6.5.
* rc/maint-http-no-head-pack-check (2009-09-09) 1 commit.
- http.c: remove verification of remote packs
This is the response to infamous "github sometimes gives status 500
error for a HEAD request even when GET request for the same URL happily
serves the content error-free." problem.
I am hoping this is safe for 1.6.5, but will wait for a response to my
inquiry earlier.
--------------------------------------------------
[Stalled]
* jh/notes (2009-08-27) 12 commits.
The reroll was discussed on the list; unfortunately it did not quite apply
to any of my branches. I do not think this has to be in 1.6.5, but I just
want to get us unstuck if Johan was waiting for me to apply the current
series before making his next move.
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
It would be a good change for 1.6.5 when done properly, but this does not
honor --confirm=never but talks to the terminal. Nor it honors any
existing sendemail.confirm configuration settings.
--------------------------------------------------
[Cooking]
* db/vcs-helper (2009-09-03) 16 commits
- ...
(merged to 'next' on 2009-09-11 at a275aa3)
+ Use a clearer style to issue commands to remote helpers
+ Make the "traditionally-supported" URLs a special case
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper.)
Up to the part that eject -lcurl from the main "git" binary cleanly are
now in 'next' and is ready for 1.6.5.
* cb/maint-1.6.3-grep-relative-up (2009-09-05) 2 commits.
(merged to 'next' on 2009-09-07 at f9b5b48)
+ grep: accept relative paths outside current working directory
+ grep: fix exit status if external_grep() punts
1.6.5 material.
* jk/unwanted-advices (2009-09-06) 2 commits
- status: make "how to stage" messages optional
- push: make non-fast-forward help message configurable
If I missed the v2 or later that uses 'advice.*" instead, I am sorry, and
please let me know. At least the first one should be in 1.6.5, I think,
and probably both.
* jt/pushinsteadof (2009-09-07) 2 commits
(merged to 'next' on 2009-09-11 at cf3eb57)
+ Add url.<base>.pushInsteadOf: URL rewriting for push only
+ Wrap rewrite globals in a struct in preparation for adding another set
Probably 1.6.5 material.
* pk/fast-import-tars (2009-09-03) 1 commit
(merged to 'next' on 2009-09-07 at 8fbf027)
+ import-tars: Allow per-tar author and commit message.
* pk/fast-import-dirs (2009-09-03) 1 commit
(merged to 'next' on 2009-09-07 at 836cba2)
+ Add script for importing bits-and-pieces to Git.
I have to wonder if there are standard libraries to do this sort of thing
without having to hand-roll these logic every time, but I decided not to
be picky about contrib/ material. Both will be in 1.6.5
* jc/maint-1.6.0-blank-at-eof (2009-09-05) 10 commits.
(merged to 'next' on 2009-09-07 at 165dc3c)
Possibly a 1.6.5 material, but it started rather late in the cycle so we
might want to cook it for a while in 'next' and do 1.6.5 without it.
* sr/gfi-options (2009-09-06) 6 commits
(merged to 'next' on 2009-09-07 at 5f6b0ff)
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: test the new feature command
+ fast-import: add feature command
+ fast-import: put marks reading in it's own function
+ fast-import: put option parsing code in separate functions
Perhaps 1.6.5 material but I wasn't sure. I saw Sverre asking Shawn for
opinion but I may have missed the response.
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
- Prepare 'traverse_trees()' for D/F conflict lookahead
Beginning of the fix to a rather nasty longstanding issue of merging trees
with ("a" "a-b"), ("a/b" "a-b") and just ("a-b"), but my reading of it is
that it is just the first step to demonstrate one-entry lookahead and not
a full solution yet.
This is a good problem to tackle but the bug has been there from the
beginning of unpack_trees(), i.e. lacks urgency, and the full solution is
expected to be much larger. I am tempted to say that 1.6.5 shouldn't wait
for this series.
^ permalink raw reply
* Re: one half of a rebase
From: Geoffrey Irving @ 2009-09-12 2:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Dylan Simon
In-Reply-To: <81b0412b0909111410k3f3ebfaco393bb37ff5a6b5c1@mail.gmail.com>
On Fri, Sep 11, 2009 at 5:10 PM, Alex Riesen<raa.lkml@gmail.com> wrote:
> On Fri, Sep 11, 2009 at 19:25, Geoffrey Irving <irving@naml.us> wrote:
>> If I could do (2) as a separate operation, it would look something like
>>
>> git cherry-pick-all topic
>>
>> which is simpler and faster since it avoids switching files back and
>> forth (master to topic and back). Is there a robust way to achieve
>> the cherry-pick-all semantics with current commands? If not, how
>> difficult would it be to partition rebase accordingly?
>
> I have this in my .bashrc:
>
> $ gcp3 ()
> {
> git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> }
>
> Then, while on master branch:
>
> $ gcp3 master..topic
Great! That should work nicely.
Geoffrey
^ permalink raw reply
* [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
From: Nicolas Sebrecht @ 2009-09-12 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Nanako Shiraishi, git, Pierre Habouzit
In-Reply-To: <7v8wglw60x.fsf@alter.siamese.dyndns.org>
[ Thank you (again) for this very good explanation. ]
The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> > Ok. So, the fact that the usage of git-am doesn't tell about
> > --no-scissors is the expected behaviour?
>
> You _could_ argue that we _could_ describe a long option "frotz" that
> lacks the '!' flag in OPTIONS_SPEC as "--[no-]frotz" in the output by
> changing the rev-parse --parseopt, if you really want to.
>
> However, I think that is not done deliberately to avoid cluttering the
> output. I Cc'ed the primary guilty party ;-) of the parse-options
> infrastructure.
Well, if it is expected to not have the "--[no-]frotz" in usage where
applicable I'll be fine with that (even if it may sounds a bit odd for a
sane user). Otherwise, I believe it could be a (small) improvement for
the UI.
> Currently, non-bool options are not marked with '!'. Nobody sane would
> say "git am --no-directory foo", but "rev-parse --parseopt" acccepts such
> a nonsense input, and it is up to the calling script to catch it and barf.
> But "rev-parse --parseopt" will start saying "--[no-]directory=" with such
> a change, which is not good.
>
> And --no-scissors is not that special. We could add --no-signoff to say
> "I do not want to sign-off this one time" explicitly, and it is crazy if
> we had to add another line in OPTIONS_SPEC when we want to do so, when it
> is clear "signoff" option is a boolean.
>
> As a long term direction, I'd rather not to see "no-" in OPTIONS_SPEC, but
> have that taken care of by "rev-parse --parseopt" to keep our sanity. The
> only existing offender is "no-verify" in "rebase -i". Let's solve it (if
> there is anything to solve, which I doubt) without adding new ones.
Now (with all this background in mind), I agree that the "no-" in
OPTIONS_SPEC looks ugly.
<If there were something to change>
As you say, we can't blindly rely on the "is a boolean" and "option name
begin with 'no-'" things altogether. Perhaps a new magic character
('-'?) beside the current flags of PARSEOPT could smartly do the trick?
</>
Pierre, opinion?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH 1/2] start_command: do not clobber cmd->env on Windows code path
From: Junio C Hamano @ 2009-09-12 4:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, Alexey Borzenkov, git
In-Reply-To: <200909111940.08652.j6t@kdbg.org>
Thanks; both patches applied.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Junio C Hamano @ 2009-09-12 4:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Jeff King,
Johannes Schindelin, Daniel Barkalow, Jan Engelhardt,
Johan Herland, Linus Torvalds
In-Reply-To: <7veiqdngs0.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jk/unwanted-advices (2009-09-06) 2 commits
> - status: make "how to stage" messages optional
> - push: make non-fast-forward help message configurable
>
> If I missed the v2 or later that uses 'advice.*" instead, I am sorry, and
> please let me know.
Found them; thanks.
^ permalink raw reply
* Re: [PATCH] preserve mtime of local clone
From: Junio C Hamano @ 2009-09-12 5:09 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, msysgit, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20090909195158.GA12968@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> +int copy_times(int ofd, int ifd)
> +{
> + struct stat st;
> + struct timespec times[2];
> + if (fstat(ifd, &st))
> + return -1;
> + times[0].tv_nsec = UTIME_OMIT;
> + times[1].tv_sec = st.st_mtime;
> + times[1].tv_nsec = ST_MTIME_NSEC(st);
> + return futimens(ofd, times);
> +}
Hmm, futimens() is relatively new. Are minority platforms folks Ok with
this patch?
At least SunOS 5.11 (OpenSolaris 0811) seems to barf on UTIME_OMIT.
^ permalink raw reply
* [PATCH 2/2] Re: Makefile: remove unused CURL_SYNONYMS variable
From: Nicolas Sebrecht @ 2009-09-12 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Daniel Barkalow, Mike Ralphson, git
In-Reply-To: <7vd45wloj4.fsf@alter.siamese.dyndns.org>
The 11/09/09, Junio C Hamano wrote:
>
> This looks wrong. What's filtering out of what?
>
> I think you meant to finish the revert of ad17f01 (Makefile: install
> hardlinks for git-remote-<scheme> supported by libcurl if possible,
> 2009-08-07) that c9e388b (Make the "traditionally-supported" URLs a
> special case, 2009-09-03) attempted to do but missed.
>
> Perhaps you meant to do this?
>
> diff --git a/Makefile b/Makefile
> index 8c44e35..1ac02d1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1655,7 +1655,7 @@ export gitexec_instdir
> install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
> - $(INSTALL) $(filter-out $(CURL_SYNONYMS), $(ALL_PROGRAMS)) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
> + $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
> $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
> $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
> ifndef NO_PERL
Yes, exactly. Sorry for the mistake.
Oh, and I just saw that my sendemail.cc configuration has been ignored
resulting in not cc'ing the mailing list (fixed for this mail). I guess
it comes from some --cc options added at command line. Shouldn't --cc
add new cc to the cc list instead of override sendemail.cc?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] preserve mtime of local clone
From: Clemens Buchacher @ 2009-09-12 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Shawn O. Pearce
In-Reply-To: <7vmy50lpfr.fsf@alter.siamese.dyndns.org>
On Fri, Sep 11, 2009 at 10:09:12PM -0700, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > +int copy_times(int ofd, int ifd)
> > +{
> > + struct stat st;
> > + struct timespec times[2];
> > + if (fstat(ifd, &st))
> > + return -1;
> > + times[0].tv_nsec = UTIME_OMIT;
> > + times[1].tv_sec = st.st_mtime;
> > + times[1].tv_nsec = ST_MTIME_NSEC(st);
> > + return futimens(ofd, times);
> > +}
>
> Hmm, futimens() is relatively new. Are minority platforms folks Ok with
> this patch?
>
> At least SunOS 5.11 (OpenSolaris 0811) seems to barf on UTIME_OMIT.
If it's a problem we can use utime() instead. I was just trying to use the
file descriptors, since they were available. But the patch would be a little
smaller if I didn't touch copy_fd().
Clemens
^ permalink raw reply
* [PATCH] use write_str_in_full helper to avoid literal string lengths
From: Jim Meyering @ 2009-09-12 8:54 UTC (permalink / raw)
To: git list
In next's 2d14d65ce7b136b0fb18dcf27e5caff67829f658,
I happened to notice two changes like this:
- write_in_full(helper->in, "list\n", 5);
+
+ strbuf_addstr(&buf, "list\n");
+ write_in_full(helper->in, buf.buf, buf.len);
+ strbuf_reset(&buf);
IMHO, it would be better to define a new function,
static inline ssize_t write_str_in_full(int fd, const char *str)
{
return write_in_full(fd, str, strlen(str));
}
and then use it like this:
- strbuf_addstr(&buf, "list\n");
- write_in_full(helper->in, buf.buf, buf.len);
- strbuf_reset(&buf);
+ write_str_in_full(helper->in, "list\n");
Thus not requiring the added allocation, and still avoiding
the maintenance risk of literal string lengths.
These days, compilers are good enough that strlen("literal")
imposes no run-time cost.
Transformed via this:
perl -pi -e \
's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\
$(git grep -l 'write_in_full.*"')
>From fe368f8b3720f04c9dfce952711d2fb412b52e3c Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Sat, 12 Sep 2009 09:56:13 +0200
Subject: [PATCH] use write_str_in_full helper to avoid literal string lengths
* cache.h (write_str_in_full): Define function.
* builtin-fetch.c (quickfetch): Use it.
* builtin-reflog.c (expire_reflog): Likewise.
* commit.c (write_shallow_commits): Likewise.
* config.c (git_config_set_multivar): Likewise.
* rerere.c (write_rr): Likewise.
* transport-helper.c (get_helper, disconnect_helper): Likewise.
(get_refs_list): Likewise.
* upload-pack.c (receive_needs): Likewise.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
builtin-fetch.c | 2 +-
builtin-reflog.c | 2 +-
cache.h | 9 +++++++--
commit.c | 2 +-
config.c | 2 +-
rerere.c | 2 +-
transport-helper.c | 10 +++-------
upload-pack.c | 4 ++--
8 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 817dd6b..cb48c57 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -454,7 +454,7 @@ static int quickfetch(struct ref *ref_map)
for (ref = ref_map; ref; ref = ref->next) {
if (write_in_full(revlist.in, sha1_to_hex(ref->old_sha1), 40) < 0 ||
- write_in_full(revlist.in, "\n", 1) < 0) {
+ write_str_in_full(revlist.in, "\n") < 0) {
if (errno != EPIPE && errno != EINVAL)
error("failed write to rev-list: %s", strerror(errno));
err = -1;
diff --git a/builtin-reflog.c b/builtin-reflog.c
index 95198c5..e23b5ef 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -362,7 +362,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
} else if (cmd->updateref &&
(write_in_full(lock->lock_fd,
sha1_to_hex(cb.last_kept_sha1), 40) != 40 ||
- write_in_full(lock->lock_fd, "\n", 1) != 1 ||
+ write_str_in_full(lock->lock_fd, "\n") != 1 ||
close_ref(lock) < 0)) {
status |= error("Couldn't write %s",
lock->lk->filename);
diff --git a/cache.h b/cache.h
index 30a7a16..90bf127 100644
--- a/cache.h
+++ b/cache.h
@@ -924,13 +924,18 @@ extern const char *git_mailmap_file;
extern void maybe_flush_or_die(FILE *, const char *);
extern int copy_fd(int ifd, int ofd);
extern int copy_file(const char *dst, const char *src, int mode);
-extern ssize_t read_in_full(int fd, void *buf, size_t count);
-extern ssize_t write_in_full(int fd, const void *buf, size_t count);
extern void write_or_die(int fd, const void *buf, size_t count);
extern int write_or_whine(int fd, const void *buf, size_t count, const char *msg);
extern int write_or_whine_pipe(int fd, const void *buf, size_t count, const char *msg);
extern void fsync_or_die(int fd, const char *);
+extern ssize_t read_in_full(int fd, void *buf, size_t count);
+extern ssize_t write_in_full(int fd, const void *buf, size_t count);
+static inline ssize_t write_str_in_full(int fd, const char *str)
+{
+ return write_in_full(fd, str, strlen(str));
+}
+
/* pager.c */
extern void setup_pager(void);
extern const char *pager_program;
diff --git a/commit.c b/commit.c
index a6c6f70..fedbd5e 100644
--- a/commit.c
+++ b/commit.c
@@ -212,7 +212,7 @@ int write_shallow_commits(int fd, int use_pack_protocol)
else {
if (write_in_full(fd, hex, 40) != 40)
break;
- if (write_in_full(fd, "\n", 1) != 1)
+ if (write_str_in_full(fd, "\n") != 1)
break;
}
}
diff --git a/config.c b/config.c
index f21530c..c644061 100644
--- a/config.c
+++ b/config.c
@@ -1119,7 +1119,7 @@ int git_config_set_multivar(const char *key, const char *value,
copy_end - copy_begin)
goto write_err_out;
if (new_line &&
- write_in_full(fd, "\n", 1) != 1)
+ write_str_in_full(fd, "\n") != 1)
goto write_err_out;
}
copy_begin = store.offset[i];
diff --git a/rerere.c b/rerere.c
index 87360dc..29f95f6 100644
--- a/rerere.c
+++ b/rerere.c
@@ -61,7 +61,7 @@ static int write_rr(struct string_list *rr, int out_fd)
path = rr->items[i].string;
length = strlen(path) + 1;
if (write_in_full(out_fd, rr->items[i].util, 40) != 40 ||
- write_in_full(out_fd, "\t", 1) != 1 ||
+ write_str_in_full(out_fd, "\t") != 1 ||
write_in_full(out_fd, path, length) != length)
die("unable to write rerere record");
}
diff --git a/transport-helper.c b/transport-helper.c
index b1ea7e6..832d81f 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -37,9 +37,7 @@ static struct child_process *get_helper(struct transport *transport)
die("Unable to run helper: git %s", helper->argv[0]);
data->helper = helper;
- strbuf_addstr(&buf, "capabilities\n");
- write_in_full(helper->in, buf.buf, buf.len);
- strbuf_reset(&buf);
+ write_str_in_full(helper->in, "capabilities\n");
file = fdopen(helper->out, "r");
while (1) {
@@ -58,7 +56,7 @@ static int disconnect_helper(struct transport *transport)
{
struct helper_data *data = transport->data;
if (data->helper) {
- write_in_full(data->helper->in, "\n", 1);
+ write_str_in_full(data->helper->in, "\n");
close(data->helper->in);
finish_command(data->helper);
free((char *)data->helper->argv[0]);
@@ -124,9 +122,7 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
helper = get_helper(transport);
- strbuf_addstr(&buf, "list\n");
- write_in_full(helper->in, buf.buf, buf.len);
- strbuf_reset(&buf);
+ write_str_in_full(helper->in, "list\n");
file = fdopen(helper->out, "r");
while (1) {
diff --git a/upload-pack.c b/upload-pack.c
index c77ab71..b3471e4 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -553,7 +553,7 @@ static void receive_needs(void)
shallow_nr = 0;
if (debug_fd)
- write_in_full(debug_fd, "#S\n", 3);
+ write_str_in_full(debug_fd, "#S\n");
for (;;) {
struct object *o;
unsigned char sha1_buf[20];
@@ -619,7 +619,7 @@ static void receive_needs(void)
}
}
if (debug_fd)
- write_in_full(debug_fd, "#E\n", 3);
+ write_str_in_full(debug_fd, "#E\n");
if (!use_sideband && daemon_mode)
no_progress = 1;
--
1.6.5.rc0.190.g15871
^ permalink raw reply related
* [PATCH] preserve mtime of local clone
From: Clemens Buchacher @ 2009-09-12 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Shawn O. Pearce
In-Reply-To: <20090912082624.GA9654@localhost>
A local clone without hardlinks copies all objects, including dangling
ones, to the new repository. Since the mtimes are renewed, those
dangling objects cannot be pruned by "git gc --prune", even if they
would have been old enough for pruning in the original repository.
Instead, preserve mtime during copy. "git gc --prune" will then work
in the clone just like it did in the original.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Sat, Sep 12, 2009 at 10:26:24AM +0200, Clemens Buchacher wrote:
> If it's a problem we can use utime() instead. I was just trying to use the
> file descriptors, since they were available. But the patch would be a little
> smaller if I didn't touch copy_fd().
Here we go.
builtin-clone.c | 2 +-
builtin-init-db.c | 2 +-
cache.h | 4 +++-
copy.c | 18 +++++++++++++++++-
rerere.c | 2 +-
5 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index ad04808..cb3c895 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -269,7 +269,7 @@ static void copy_or_link_directory(struct strbuf *src, struct strbuf *dest)
die_errno("failed to create link '%s'", dest->buf);
option_no_hardlinks = 1;
}
- if (copy_file(dest->buf, src->buf, 0666))
+ if (copy_file(dest->buf, src->buf, 0666, 1))
die_errno("failed to copy file to '%s'", dest->buf);
}
closedir(dir);
diff --git a/builtin-init-db.c b/builtin-init-db.c
index dd84cae..5deb81d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -100,7 +100,7 @@ static void copy_templates_1(char *path, int baselen,
die_errno("cannot symlink '%s' '%s'", lnk, path);
}
else if (S_ISREG(st_template.st_mode)) {
- if (copy_file(path, template, st_template.st_mode))
+ if (copy_file(path, template, st_template.st_mode, 0))
die_errno("cannot copy '%s' to '%s'", template,
path);
}
diff --git a/cache.h b/cache.h
index 5fad24c..ac692d0 100644
--- a/cache.h
+++ b/cache.h
@@ -922,7 +922,9 @@ extern const char *git_mailmap_file;
/* IO helper functions */
extern void maybe_flush_or_die(FILE *, const char *);
extern int copy_fd(int ifd, int ofd);
-extern int copy_file(const char *dst, const char *src, int mode);
+extern int copy_file(const char *dst, const char *src, int mode, int
+ preserve_times);
+extern int copy_times(const char *dst, const char *src);
extern ssize_t read_in_full(int fd, void *buf, size_t count);
extern ssize_t write_in_full(int fd, const void *buf, size_t count);
extern void write_or_die(int fd, const void *buf, size_t count);
diff --git a/copy.c b/copy.c
index e54d15a..fb5e946 100644
--- a/copy.c
+++ b/copy.c
@@ -35,7 +35,21 @@ int copy_fd(int ifd, int ofd)
return 0;
}
-int copy_file(const char *dst, const char *src, int mode)
+int copy_times(const char *dst, const char *src)
+{
+ struct stat st;
+ struct utimbuf times;
+ if (stat(src, &st) < 0)
+ return -1;
+ times.actime = st.st_atime;
+ times.modtime = st.st_mtime;
+ if (utime(dst, ×) < 0)
+ return -1;
+ return 0;
+}
+
+int copy_file(const char *dst, const char *src, int mode,
+ int preserve_times)
{
int fdi, fdo, status;
@@ -52,6 +66,8 @@ int copy_file(const char *dst, const char *src, int mode)
if (!status && adjust_shared_perm(dst))
return -1;
+ if (!status && preserve_times && copy_times(dst, src))
+ return -1;
return status;
}
diff --git a/rerere.c b/rerere.c
index 87360dc..d25f5f1 100644
--- a/rerere.c
+++ b/rerere.c
@@ -326,7 +326,7 @@ static int do_plain_rerere(struct string_list *rr, int fd)
continue;
fprintf(stderr, "Recorded resolution for '%s'.\n", path);
- copy_file(rerere_path(name, "postimage"), path, 0666);
+ copy_file(rerere_path(name, "postimage"), path, 0666, 0);
mark_resolved:
rr->items[i].util = NULL;
}
--
1.6.5.rc0.164.g5f6b0
^ permalink raw reply related
* [PATCH] don't dereference NULL upon fdopen failure
From: Jim Meyering @ 2009-09-12 9:16 UTC (permalink / raw)
To: git list
While making today's write_in_full -> write_str_in_full changes,
I noticed some unchecked fdopen uses. A few were already checked,
but several others were not. The patch below changes each unchecked
one to xfdopen.
>From 0cbde9e065a309f75a44a32f7ecc7453e0d482cf Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Sat, 12 Sep 2009 10:43:27 +0200
Subject: [PATCH] don't dereference NULL upon fdopen failure
* builtin-add.c (edit_patch): Use xfdopen instead.
* builtin-mailsplit.c (split_one): Likewise.
* bundle.c (create_bundle): Likewise.
* transport-helper.c (get_helper, fetch_with_fetch): Likewise.
(get_refs_list): Likewise.
* upload-pack.c (do_rev_list, create_pack_file): Likewise.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
builtin-add.c | 2 +-
builtin-mailsplit.c | 2 +-
bundle.c | 2 +-
transport-helper.c | 6 +++---
upload-pack.c | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index a571473..cb6e590 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -198,7 +198,7 @@ static int edit_patch(int argc, const char **argv, const char *prefix)
out = open(file, O_CREAT | O_WRONLY, 0644);
if (out < 0)
die ("Could not open '%s' for writing.", file);
- rev.diffopt.file = fdopen(out, "w");
+ rev.diffopt.file = xfdopen(out, "w");
rev.diffopt.close_file = 1;
if (run_diff_files(&rev, 0))
die ("Could not write patch");
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index ee6ca0e..dfe5b15 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -64,7 +64,7 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
fd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd < 0)
die_errno("cannot open output file '%s'", name);
- output = fdopen(fd, "w");
+ output = xfdopen(fd, "w");
/* Copy it out, while searching for a line that begins with
* "From " and having something that looks like a date format.
diff --git a/bundle.c b/bundle.c
index e4b2aa9..df95e15 100644
--- a/bundle.c
+++ b/bundle.c
@@ -234,7 +234,7 @@ int create_bundle(struct bundle_header *header, const char *path,
rls.git_cmd = 1;
if (start_command(&rls))
return -1;
- rls_fout = fdopen(rls.out, "r");
+ rls_fout = xfdopen(rls.out, "r");
while (fgets(buffer, sizeof(buffer), rls_fout)) {
unsigned char sha1[20];
if (buffer[0] == '-') {
diff --git a/transport-helper.c b/transport-helper.c
index 832d81f..f57e84c 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -39,7 +39,7 @@ static struct child_process *get_helper(struct transport *transport)
write_str_in_full(helper->in, "capabilities\n");
- file = fdopen(helper->out, "r");
+ file = xfdopen(helper->out, "r");
while (1) {
if (strbuf_getline(&buf, file, '\n') == EOF)
exit(128); /* child died, message supplied already */
@@ -71,7 +71,7 @@ static int fetch_with_fetch(struct transport *transport,
int nr_heads, const struct ref **to_fetch)
{
struct child_process *helper = get_helper(transport);
- FILE *file = fdopen(helper->out, "r");
+ FILE *file = xfdopen(helper->out, "r");
int i;
struct strbuf buf = STRBUF_INIT;
@@ -124,7 +124,7 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
write_str_in_full(helper->in, "list\n");
- file = fdopen(helper->out, "r");
+ file = xfdopen(helper->out, "r");
while (1) {
char *eov, *eon;
if (strbuf_getline(&buf, file, '\n') == EOF)
diff --git a/upload-pack.c b/upload-pack.c
index b3471e4..38ddac2 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -108,7 +108,7 @@ static int do_rev_list(int fd, void *create_full_pack)
int i;
struct rev_info revs;
- pack_pipe = fdopen(fd, "w");
+ pack_pipe = xfdopen(fd, "w");
init_revisions(&revs, NULL);
revs.tag_objects = 1;
revs.tree_objects = 1;
@@ -255,7 +255,7 @@ static void create_pack_file(void)
/* pass on revisions we (don't) want */
if (!shallow_nr) {
- FILE *pipe_fd = fdopen(pack_objects.in, "w");
+ FILE *pipe_fd = xfdopen(pack_objects.in, "w");
if (!create_full_pack) {
int i;
for (i = 0; i < want_obj.nr; i++)
--
1.6.5.rc0.190.g15871
^ permalink raw reply related
* [PATCH] transport-helper.c: don't leak fdopen'd stream buffers
From: Jim Meyering @ 2009-09-12 9:38 UTC (permalink / raw)
To: git list
Looking in the vicinity today, I noticed that these
fdopen'd streams were never fclosed; technically a leak
of both the FILE buffer and the file descriptor.
>From aeae4edb1146b107f6a397118db8b0ac06b884d9 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Sat, 12 Sep 2009 11:35:17 +0200
Subject: [PATCH] transport-helper.c: don't leak fdopen'd stream buffers
* transport-helper.c (get_helper, fetch_with_fetch, get_refs_list):
Call fclose on each just-created FILE* pointer, when done.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
transport-helper.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index f57e84c..0bbd014 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -49,6 +49,7 @@ static struct child_process *get_helper(struct transport *transport)
if (!strcmp(buf.buf, "fetch"))
data->fetch = 1;
}
+ fclose (file);
return data->helper;
}
@@ -88,6 +89,7 @@ static int fetch_with_fetch(struct transport *transport,
if (strbuf_getline(&buf, file, '\n') == EOF)
exit(128); /* child died, message supplied already */
}
+ fclose (file);
return 0;
}
@@ -147,6 +149,7 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
get_sha1_hex(buf.buf, (*tail)->old_sha1);
tail = &((*tail)->next);
}
+ fclose (file);
strbuf_release(&buf);
for (posn = ret; posn; posn = posn->next)
--
1.6.5.rc0.190.g15871
^ permalink raw reply related
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-12 10:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Tom Preston-Werner, Jakub Narebski
In-Reply-To: <7veiqdzwrk.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, Sep 11, 2009 at 4:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> - You fetch, and the walker walks the loose objects, and then finds one
> object that cannot be obtained as a loose object. It tries to look up
> in the *.idx file and finds it in B.
>
> But the packfile B is long gone.
>
> I didn't follow the codepath that uses http_get_info_packs() and then uses
> repo->packs list to see what it does, but as long as the above does not
> happen we should be Ok.
To determine which pack to get when fetching an object, http-walker.c
does not refer to the *.idx files git already has (that is, those
found locally). Instead, it builds a list of *.idx files (repo->packs
or walker->data->alt->packs) from the remote's objects/info/packs, and
uses that.
So even if the *.idx file for pack B was downloaded from a previous
fetch, it won't be used at all.
Therefore, your concern (over fetching a non-existent pack) won't play
out, unless the server does a repack -a, but forgets to update the
pack list (at objects/info/packs).
PS. The above was solely based on my reading of the code, no testing done.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Dmitry Potapov @ 2009-09-12 10:31 UTC (permalink / raw)
To: Brendan Miller; +Cc: Jakub Narebski, git
In-Reply-To: <ef38762f0909091709t7336d86dkd2f175e5b3a6a3f@mail.gmail.com>
On Wed, Sep 09, 2009 at 05:09:31PM -0700, Brendan Miller wrote:
> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Brendan Miller <catphive@catphive.net> writes:
> >>
> >> This is what I want to do 90% of the time, so it should just have the
> >> proper defaults, and not make me look at the man page every time I
> >> want to use it.
> >
> > You learn those idioms.
>
> I guess. Is that a good thing?
In general, yes, because most of them exist for a good reason.
> Is the goal of interface design to make
> it difficult so I need to learn a lot of things, or easy so I can
> remain blissfully ignorant but still do what I want?
Neither. You cannot get what unless you have specified what you want,
and for that you have to learn how to say that. Having good defaults is
very important, but the problem with choosing them is that people have
different preferences about them. For instance, you wanted the default
prefix for git-archive to be $myproject. For me, a good default would be
either $tag_name, or $myproject-$tag_name, or empty (as it is now!). So,
what you propose is *never* a good default for me. Moreover, changing
any default will cause a lot of pain for other people who use Git now.
Besides, writing something like --prefix='' is very ugly. So, the
current default makes perfect sense.
> >>
> >> 7. Man pages: It's nice we have them, but we shouldn't need them to do
> >> basic stuff. I rarely had to look at the man pages using svn, but
> >> every single time I use git I have to dig into these things. Frankly,
> >> I have better things to do than RTFM.
> >
> > Learn. If you learn the philosophy behind git design, you would have
> > much easier understanding and remembering git.
>
> I think what you mean by philosophy is the underlying data structures,
> which are discussed in the manual
I think I have read them a lot, but I do not remember any underlying
data structures described in them. What are you reading?
> If I use GCC, do I need to know that it has a recursive descent
> parser? That it is implemented with a garbage collector? No. I just
> need to know that I give it C, and it gives me a binary.
>
> Example:
> gcc main.c
The fallacy in your logic is that you compare two completely different
things thinking about them as almost identical. In case of GCC, the file
contains a program written in the C language. If you do not learn the C
language, you will not be able to use GCC. On the other hand, for Git
any file is just bytes, but the command-line interface describes what
you want to do with them. There is no single action that would make
sense in all cases, you have to specify what you want. Even with simple
tools like sed or awk, you have to learn something before you can use
them.
> >
> > There is "Git User's Manual", "The Git Community Book", "Pro Git" and
> > many other references.
>
> Yeah, I've been reading them. I'm saying that the docs are a crutch.
> RTFM is the problem not the solution. It makes the user do more work
> to avoid fixing usability issues.
A usability issue exists when a person knows how to do that, but it is
inconvenient or error-prone; or when a learning curve is too steep.
But when someone cannot use, let's say, a compiler, because he or she
refuses to read to learn the language, it is not a usability issue.
Dmitry
^ permalink raw reply
* [PATCH] wrap git's main usage string.
From: Matthieu Moy @ 2009-09-12 10:39 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
It's now similar wrapped the same way as in Documentation/git.txt, and
fits in a 67 characters wide terminal.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
git.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 0b22595..271579c 100644
--- a/git.c
+++ b/git.c
@@ -5,7 +5,10 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
+ "git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]\n"
+ " [-p|--paginate|--no-pager]\n"
+ " [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n"
+ " [--help] COMMAND [ARGS]";
const char git_more_info_string[] =
"See 'git help COMMAND' for more information on a specific command.";
--
1.6.5.rc0.12.gbebb.dirty
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Sverre Rabbelier @ 2009-09-12 11:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Shawn O. Pearce, Jeff King, Johannes Schindelin,
Daniel Barkalow, Jan Engelhardt, Johan Herland, Linus Torvalds
In-Reply-To: <7veiqdngs0.fsf@alter.siamese.dyndns.org>
Heya,
On Sat, Sep 12, 2009 at 02:33, Junio C Hamano <gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
>
> Perhaps 1.6.5 material but I wasn't sure. I saw Sverre asking Shawn for
> opinion but I may have missed the response.
No response from Shawn so far, I assume he's short on Git budget :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Effectively tracing project contributions with git
From: Joseph Wakeling @ 2009-09-12 12:30 UTC (permalink / raw)
To: git
Hello,
I've recently begun contributing to a FOSS project that has a problem --
although it has extensive git logs (some being CVS/SVN imports) dating
back over many years, there has not been maintenance of contribution
records on a file-by-file basis.
I'm trying to rectify this and track down who contributed what.
Unfortunately while I'm used to basic operations with git, I don't know
it well enough to be confident in how to go about tracing contributions
in this way.
'git annotate' of course is a nice starting point but of limited use
because every time someone tweaks a line (and there have been many such
tweaks in the history of the project) the responsibility of the original
contributor is replaced by that of the tweaker.
An alternative is to use gitk to trace the history of individual files
(or paths, as gitk has it). The problem here is that files have been
renamed, content has been moved about between different files and so on.
Finally, there's the option to use gitk to trace contributors (someone
has prepared a .mailman file with a complete list of contributors by
name and email) and manually or otherwise tally their significant
contributions. Again, I'm not sure to what extent this is made
difficult by copy/pasting and tweaking of file content.
I'm just hoping that the git community can offer some good advice on
this, to what extent the process of tracing contributions can be
automated, and so on. I'm not expecting anyone to provide a solution
for me, but suggestions and pointers in the possible right directions
would be much appreciated.
Thanks & best wishes,
-- Joe
^ permalink raw reply
* (unknown)
From: Tito @ 2009-09-12 13:00 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply
* Re: one half of a rebase
From: Paolo Bonzini @ 2009-09-12 14:38 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Alex Riesen, git, Dylan Simon
In-Reply-To: <7f9d599f0909111923v76e0f411n16555e7cdc0c3ed1@mail.gmail.com>
On 09/12/2009 04:23 AM, Geoffrey Irving wrote:
> On Fri, Sep 11, 2009 at 5:10 PM, Alex Riesen<raa.lkml@gmail.com> wrote:
>> On Fri, Sep 11, 2009 at 19:25, Geoffrey Irving<irving@naml.us> wrote:
>>> If I could do (2) as a separate operation, it would look something like
>>>
>>> git cherry-pick-all topic
>>>
>>> which is simpler and faster since it avoids switching files back and
>>> forth (master to topic and back). Is there a robust way to achieve
>>> the cherry-pick-all semantics with current commands? If not, how
>>> difficult would it be to partition rebase accordingly?
As mentioned by Alex "git am -3" is basically parsing + the second part
of rebase. So, based on Alex's recipe, here is a possible alias for
cherry-pick-all:
[alias]
cherry-pick-all = "!f() { git format-patch -k --stdout --full-index
`git symbolic-ref HEAD`..$1 | git am -k -3 --binary; }; f"
More useful (just because it is more generic) than "the second part of
git rebase", a "sequencer" would be "the second part of git rebase -i",
applying a custom script coming from stdin. If that was present, git
cherry-pick-all could be done like this:
git log --pretty=tformat:'pick %h' master..topic | git sequencer
And here is yet another alternative, that however would only work only
if the patches applies perfectly:
git log --pretty=format:%h master..topic | xargs -rn1 git cherry-pick
Paolo
^ 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