* [RFH/Preview/PATCH] update "howto maintain git"
From: Junio C Hamano @ 2012-11-27 23:41 UTC (permalink / raw)
To: git; +Cc: peff
This is still incomplete without a documentation for two scripts,
Meta/Reintegrate and Meta/cook (both are found on my 'todo' branch
and meant to be checked out in the Meta subdirectory of git.git),
that are meant to help the maintainer workflow but can be used by
interested parties, but the old write-up of the procedure has become
really stale and no longer reflects the reality.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* It would help greatly if Peff can point out parts that he found
too sketchy to be useful, and even better fill these parts
himself, based on the recent "interim maintainer" experience.
Documentation/howto/maintain-git.txt | 176 +++++++++++++++++++++--------------
1 file changed, 106 insertions(+), 70 deletions(-)
diff --git c/Documentation/howto/maintain-git.txt w/Documentation/howto/maintain-git.txt
index ea6e4a5..a5713b4 100644
--- c/Documentation/howto/maintain-git.txt
+++ w/Documentation/howto/maintain-git.txt
@@ -12,20 +12,20 @@ How to maintain Git
The maintainer's git time is spent on three activities.
- - Communication (60%)
+ - Communication (45%)
Mailing list discussions on general design, fielding user
questions, diagnosing bug reports; reviewing, commenting on,
suggesting alternatives to, and rejecting patches.
- - Integration (30%)
+ - Integration (50%)
Applying new patches from the contributors while spotting and
correcting minor mistakes, shuffling the integration and
testing branches, pushing the results out, cutting the
releases, and making announcements.
- - Own development (10%)
+ - Own development (5%)
Scratching my own itch and sending proposed patch series out.
@@ -39,6 +39,9 @@ The policy.
contain bugfixes and enhancements in any area, including
functionality, performance and usability, without regression.
+ - One release cycle for a feature release is expected to last for
+ eight to ten weeks.
+
- Maintenance releases are numbered as vX.Y.Z.W and are meant
to contain only bugfixes for the corresponding vX.Y.Z feature
release and earlier maintenance releases vX.Y.Z.V (V < W).
@@ -62,12 +65,15 @@ The policy.
- 'pu' branch is used to publish other proposed changes that do
not yet pass the criteria set for 'next'.
- - The tips of 'master', 'maint' and 'next' branches will always
- fast-forward, to allow people to build their own
- customization on top of them.
+ - The tips of 'master' and 'maint' branches will not be rewound to
+ allow people to build their own customization on top of them.
+ Early in a new development cycle, 'next' is rewound to the tip of
+ 'master' once, but otherwise it will not be rewound until the end
+ of the cycle.
- - Usually 'master' contains all of 'maint', 'next' contains all
- of 'master' and 'pu' contains all of 'next'.
+ - Usually 'master' contains all of 'maint' and 'next' contains all
+ of 'master'. 'pu' contains all the topics merged to 'next', but
+ is rebuilt directly on 'master'.
- The tip of 'master' is meant to be more stable than any
tagged releases, and the users are encouraged to follow it.
@@ -80,11 +86,15 @@ The policy.
A typical git day for the maintainer implements the above policy
by doing the following:
- - Scan mailing list and #git channel log. Respond with review
- comments, suggestions etc. Kibitz. Collect potentially
- usable patches from the mailing list. Patches about a single
- topic go to one mailbox (I read my mail in Gnus, and type
- \C-o to save/append messages in files in mbox format).
+ - Scan mailing list. Respond with review comments, suggestions
+ etc. Kibitz. Collect potentially usable patches from the
+ mailing list. Patches about a single topic go to one mailbox (I
+ read my mail in Gnus, and type \C-o to save/append messages in
+ files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+ nobody has stepped up solving. Send it out just like other
+ contributors do.
- Review the patches in the saved mailboxes. Edit proposed log
message for typofixes and clarifications, and add Acks
@@ -100,28 +110,25 @@ by doing the following:
- Obviously correct fixes that pertain to the tip of 'master'
are directly applied to 'master'.
+ - Other topics are not handled in this step.
+
This step is done with "git am".
$ git checkout master ;# or "git checkout maint"
$ git am -3 -s mailbox
$ make test
- - Merge downwards (maint->master):
-
- $ git checkout master
- $ git merge maint
- $ make test
-
- Review the last issue of "What's cooking" message, review the
topics scheduled for merging upwards (topic->master and
- topic->maint), and merge.
+ topic->maint), and merge. Use "Meta/cook -w" script (see later)
+ to aid this step.
$ git checkout master ;# or "git checkout maint"
$ git merge ai/topic ;# or "git merge ai/maint-topic"
$ git log -p ORIG_HEAD.. ;# final review
$ git diff ORIG_HEAD.. ;# final review
$ make test ;# final review
- $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
+XXX $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
- Merge downwards (maint->master) if needed:
@@ -142,9 +149,9 @@ by doing the following:
and not in 'master') is applied to a new topic branch that
is forked from the tip of 'master'. This includes both
enhancements and unobvious fixes to 'master'. A topic
- branch is named as ai/topic where "ai" is typically
- author's initial and "topic" is a descriptive name of the
- topic (in other words, "what's the series is about").
+ branch is named as ai/topic where "ai" is two-letter string
+ named after author's initial and "topic" is a descriptive name
+ of the topic (in other words, "what's the series is about").
- An unobvious fix meant for 'maint' is applied to a new
topic branch that is forked from the tip of 'maint'. The
@@ -162,6 +169,7 @@ by doing the following:
The above except the "replacement" are all done with:
+ $ git checkout ai/topic ;# or "git checkout -b ai/topic master"
$ git am -3 -s mailbox
while patch replacement is often done by:
@@ -170,6 +178,7 @@ by doing the following:
then replace some parts with the new patch, and reapplying:
+ $ git checkout ai/topic
$ git reset --hard ai/topic~$n
$ git am -3 -s 000*.txt
@@ -177,80 +186,107 @@ by doing the following:
after patch application; for topic branches the tests are run
as time permits.
- - Update "What's cooking" message to review the updates to
- existing topics, newly added topics and graduated topics.
+ - Review the last issue of "What's cooking" again and see if topics
+ that were scheduled to be merged to 'next' are still in good
+ shape (e.g. has there any new issue identified on the list with
+ the series?)
- This step is helped with Meta/cook script (where Meta/ contains
- a checkout of the 'todo' branch).
+ - Prepare 'jch' branch, which is used to represent somewhere
+ between 'master' and 'pu' and often mirrors 'next'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-jch.sh
+
+ The result is a script that lists topics to be merged in order to
+ rebuild 'pu' as the input to Meta/Reintegrate script. Remove
+ later topics that should not be in 'next' yet.
- Merge topics to 'next'. For each branch whose tip is not
merged to 'next', one of three things can happen:
- - The commits are all next-worthy; merge the topic to next:
+ - The commits are all next-worthy; merge the topic to next;
+ - The new parts are of mixed quality, but earlier ones are
+ next-worthy; merge the early parts to next;
+ - Nothing is next-worthy; do not do anything.
- $ git checkout next
- $ git merge ai/topic ;# or "git merge ai/maint-topic"
- $ make test
+ This step is aided with Meta/redo-jch.sh script created earlier.
+ If a topic that was already in 'next' gained a patch, the script
+ would list it as "ai/topic~1". To include the new patch to the
+ updated 'next', drop the "~1" part; to keep it excluded, do not
+ touch the line. If a topic that was not in 'next' should be
+ merged to 'next', add it at the end of the list. Then:
- - The new parts are of mixed quality, but earlier ones are
- next-worthy; merge the early parts to next:
+ $ git checkout -B jch master
+ $ sh Meta/redo-jch.sh
+
+ to rebuild the 'jch' branch from scratch.
+
+ Then merge the same to 'next'
$ git checkout next
- $ git merge ai/topic~2 ;# the tip two are dubious
- $ make test
+ $ git merge master ;# may turn out to be "already up to date"
+ $ sh Meta/redo-jch.sh -e
- - Nothing is next-worthy; do not do anything.
+ The "-e" option allows the merge message that comes from the
+ history of the topic and the comments in the "What's cooking" to
+ be edited. The resulting tree should match 'jch' as the same set
+ of topics are merged on 'master'; otherwise there is a mismerge.
- - [** OBSOLETE **] Optionally rebase topics that do not have any commit
- in next yet, when they can take advantage of low-level framework
- change that is merged to 'master' already.
+ $ git diff jch next
- $ git rebase master ai/topic
+ When all is well, clean up the redo-jch.sh script with
- This step is helped with Meta/git-topic.perl script to
- identify which topic is rebaseable. There also is a
- pre-rebase hook to make sure that topics that are already in
- 'next' are not rebased beyond the merged commit.
+ $ sh Meta/redo-jch.sh -u
- - [** OBSOLETE **] Rebuild "pu" to merge the tips of topics not in 'next'.
+ This removes topics listed in the script that have already been
+ merged to 'master'.
- $ git checkout pu
- $ git reset --hard next
- $ git merge ai/topic ;# repeat for all remaining topics
- $ make test
+ - Rebuild 'pu'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-pu.sh
+
+ Edit the result by adding new topics that are not still in 'pu'
+ in the script. Then
- This step is helped with Meta/PU script
+ $ git checkout -B pu jch
+ $ sh Meta/redo-pu.sh
+
+ When all is well, clean up the redo-pu.sh script with
+
+ $ sh Meta/redo-pu.sh -u
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
+
+ This step is helped with Meta/cook script (where Meta/ contains
+ a checkout of the 'todo' branch).
- - Push four integration branches to a private repository at
- k.org and run "make test" on all of them.
+ $ Meta/cook
- - Push four integration branches to /pub/scm/git/git.git at
- k.org. This triggers its post-update hook which:
+ Look for lines enclosed in "<<" and ">>"; they hold contents from
+ old file that are replaced by this integration round. After
+ verifying them, remove the old part. Review the description for
+ each topic and update its doneness and plan as needed. To review
+ the updated plan, run
- (1) runs "git pull" in $HOME/git-doc/ repository to pull
- 'master' just pushed out;
+ $ Meta/cook -w
- (2) runs "make doc" in $HOME/git-doc/, install the generated
- documentation in staging areas, which are separate
- repositories that have html and man branches checked
- out.
+ which will pick up comments given to the topics, such as "Will
+ merge to 'next'", etc. (see Meta/cook script to learn what kind
+ of phrases are supported).
- (3) runs "git commit" in the staging areas, and run "git
- push" back to /pub/scm/git/git.git/ to update the html
- and man branches.
+ - Rebuild all four (five) integration branches; Meta/Dothem script
+ may aid this step.
- (4) installs generated documentation to /pub/software/scm/git/docs/
- to be viewed from http://www.kernel.org/
+ - Rebuild documentation if the 'master' branch was updated;
+ Meta/dodoc.sh script may aid this step.
- - Fetch html and man branches back from k.org, and push four
- integration branches and the two documentation branches to
- repo.or.cz and other mirrors.
+ - Push four integration branches to public places.
Some observations to be made.
* Each topic is tested individually, and also together with
- other topics cooking in 'next'. Until it matures, none part
+ other topics cooking in 'next'. Until it matures, no part
of it is merged to 'master'.
* A topic already in 'next' can get fixes while still in
^ permalink raw reply related
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Junio C Hamano @ 2012-11-27 23:32 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <CAMP44s1G3b3XQX+=5Ag2exdy83hULbz1m0Z6UFDrhZU2TGwBMg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>> This is a re-roll of the previous series to add support to fetch and push
>>>> special modes, and refactor some related code.
>>>
>>> It seems this one got forgotten, I only see v2 in pu.
>>
>> Oops; I think that was fell through the cracks during the maintainer
>> hand-off. As the previous one has already been cooking in 'next'
>> for a week or so, I would appreciate if you send incremental updates
>> to fix or enhance what is in there.
>
> Yes, that's what I have planned for the next patches, as I already did
> for remote-hg, but the changes in remote-bzr were a bit bigger.
OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master'
soonish, but I take the above to mean that fc/remote-hg is ready
while it is better to wait for updates to fc/remote-bzr before
merging it.
Thanks.
^ permalink raw reply
* Re: Possible vulnerability to SHA-1 collisions
From: Aaron Schrab @ 2012-11-27 23:30 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Michael Hirshleifer, git
In-Reply-To: <20121127230753.GA22730@sigill.intra.peff.net>
At 18:07 -0500 27 Nov 2012, Jeff King <peff@peff.net> wrote:
>PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
> easier said than done. We do not have SHA-1 collisions yet, but if
> the md5 attacks are any indication, the innocuous file will not be
> completely clean; it will need to have some embedded binary goo that
> is mutated randomly during the collision process (which is why the
> md5 attacks were demonstrated with postscript files which _rendered_
> to look good, but contained a chunk of random bytes in a spot ignored
> by the postscript interpreter).
I don't think that really saves us though. Many formats have parts of
the file which will be ignored, such as comments in source code. With
the suggested type of attack, there isn't a requirement about which
version of the file is modified. So the attacker should be able to
generate a version of a file with an innocuous change, get the SHA-1 for
that, then add garbage comments to their malicious version of the file
to try to get the same SHA-1.
^ permalink raw reply
* Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: Heiko Voigt @ 2012-11-27 23:28 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121127190105.GQ10656@odin.tremily.us>
Hi,
On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> The v4 series leaves the remote branch amigious, but it helps you
> point the local branch at the right hash so that future calls to
>
> $ git submodule foreach 'git pull'
>
> can use the branch's .git/modules/<name>/config settings.
But IMO thats the functionality which should be implemented in submodule
update and not left to the user.
> > I would think more of some convention like:
> >
> > $ git checkout -t origin/$branch
> >
> > when first initialising the submodule with e.g.
> >
> > $ git submodule update --init --branch
> >
> > Then later calls of
> >
> > $ git submodule update --branch
> >
> > would have a branch configured to pull from. I imagine that results in
> > a similar behavior gerrit is doing on the server side?
>
> That sounds like it's doing pretty much the same thing. Can you think
> of a test that would distinguish it from my current v4 implementation?
Well the main difference is that gerrit is automatically updating the
superproject AFAIK. I would like it if we could implement the same
workflow support in the submodule script. It seems to me that this is
already proven to be useful workflow.
I do not have a test but a small draft diff (completely untested, quick and
dirty) to illustrate the approach I am talking about.
You can find the whole change at
https://github.com/hvoigt/git/commits/hv/floating_submodules_draft
and the interesting patch for easy commenting below[1].
> > How about reusing the -b|--branch option for add? Since we only change
> > the behavior when submodule.$name.update is set to branch it seems
> > reasonable to me. Opinions?
>
> That was the approach I used in v1, but people were concerned that we
> would be stomping on previously unclaimed config space. Since noone
> has pointed out other uses besides Gerrit's very similar case, I'm not
> sure if that is still an issue.
Could you point me to that mail? I cannot seem to find it in my archive.
> > > Because you need to recurse through submodules for `update --branch`
> > > even if "$subsha1" == "$sha1", I had to amend the conditional
> > > controlling that block. This broke one of the existing tests, which I
> > > "fixed" in patch 4. I think a proper fix would involve rewriting
> > >
> > > (clear_local_git_env; cd "$sm_path" &&
> > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > > test -z "$rev") || git-fetch)) ||
> > > die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > >
> > > but I'm not familiar enough with rev-list to want to dig into that
> > > yet. If feedback for the earlier three patches is positive, I'll work
> > > up a clean fix and resubmit.
> >
> > You probably need to separate your handling here. The comparison of the
> > currently checked out sha1 and the recorded sha1 is an optimization
> > which skips unnecessary fetching in case the submodules commits are
> > already correct. This code snippet checks whether the to be checked out
> > sha1 is already local and also skips the fetch if it is. We should not
> > break that.
>
> Agreed. However, determining if the target $sha1 is local should have
> nothing to do with the current checked out $subsha1.
See my draft or the diff below for an illustration of the splitup.
Cheers Heiko
[1]
diff --git a/git-submodule.sh b/git-submodule.sh
index 9ad4370..3fa1465 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -183,6 +183,7 @@ module_clone()
sm_path=$1
url=$2
reference="$3"
+ branch="$4"
quiet=
if test -n "$GIT_QUIET"
then
@@ -209,6 +210,8 @@ module_clone()
clear_local_git_env
git clone $quiet -n ${reference:+"$reference"} \
--separate-git-dir "$gitdir" "$url" "$sm_path"
+ test -n "$branch" && (cd $sm_path &&
+ git checkout -t origin/$branch)
) ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$sm_path' failed")"
fi
@@ -361,7 +364,7 @@ Use -f if you really want to add it." >&2
else
- module_clone "$sm_path" "$realrepo" "$reference" || exit
+ module_clone "$sm_path" "$realrepo" "$reference" "$local_branch" || exit
(
clear_local_git_env
cd "$sm_path" &&
@@ -577,6 +580,12 @@ handle_on_demand_update () {
fi
}
+handle_tracking_branch_update () {
+ (clear_local_git_env; cd "$sm_path" &&
+ git-checkout $branch && git-pull --ff-only) ||
+ die "$(eval_gettext "Unable to pull branch '\$branch' in submodule path '\$sm_path'")"
+}
+
#
# Update each submodule path to correct revision, using clone and checkout as needed
#
@@ -648,6 +657,7 @@ cmd_update()
cloned_modules=
module_list "$@" | {
err=
+ floating_submodules=
while read mode sha1 stage sm_path
do
die_if_unmatched "$mode"
@@ -684,7 +694,7 @@ Maybe you want to use 'update --init'?")"
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
- module_clone "$sm_path" "$url" "$reference"|| exit
+ module_clone "$sm_path" "$url" "$reference" "$branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -693,7 +703,13 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
fi
- handle_on_demand_update
+ if test "$update_module" = "branch"
+ then
+ handle_tracking_branch_update
+ floating_submodules="$floating_submodules $sm_path"
+ else
+ handle_on_demand_update
+ fi
if test -n "$recursive"
then
@@ -727,6 +743,11 @@ Maybe you want to use 'update --init'?")"
IFS=$OIFS
exit 1
fi
+ if test -n "$floating_submodules"
+ then
+ git add $floating_submodules &&
+ git commit -m "Updated submodules"
+ fi
}
}
^ permalink raw reply related
* [PATCH] configure.ac: fix pthreads detection on Mac OS X
From: Max Horn @ 2012-11-27 23:28 UTC (permalink / raw)
To: git; +Cc: Max Horn
The configure script checks whether certain flags are required to use
pthreads. But it did not consider that *none* might be needed (as is the
case on Mac OS X). This lead to configure adding "-mt" to the list of
flags (which does nothing on OS X except producing a warning). This in
turn triggered a compiler warning on every single file.
To solve this, we now first check if pthreads work without extra flags.
This means the check is now order dependant, hence a comment is added
explaining this, and the reasons for it.
Note that it might be possible to write an order independent test, but
it does not seem worth the extra effort required for implementing and
testing such a solution, when this simple solution exists and works.
Signed-off-by: Max Horn <max@quendi.de>
---
This is actually a revised version from my patch
"Change configure to check if pthreads are usable without any extra flags"
from July. I simply had forgotten all about it :-(.
Chers,
Max
configure.ac | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ad215cc..41ac9a5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1021,7 +1021,17 @@ if test -n "$USER_NOPTHREAD"; then
# -D_REENTRANT' or some such.
elif test -z "$PTHREAD_CFLAGS"; then
threads_found=no
- for opt in -mt -pthread -lpthread; do
+ # Attempt to compile and link some code using pthreads to determine
+ # required linker flags. The order is somewhat important here: We
+ # first try it without any extra flags, to catch systems where
+ # pthreads are part of the C library, then go on testing various other
+ # flags. We do so to avoid false positives. For example, on Mac OS X
+ # pthreads are part of the C library; moreover, the compiler allows us
+ # to add "-mt" to the CFLAGS (although it will do nothing except
+ # trigger a warning about an unused flag). Hence if we checked for
+ # "-mt" before "" we would end up picking it. But unfortunately this
+ # would then trigger compiler warnings on every single file we compile.
+ for opt in "" -mt -pthread -lpthread; do
old_CFLAGS="$CFLAGS"
CFLAGS="$opt $CFLAGS"
AC_MSG_CHECKING([for POSIX Threads with '$opt'])
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* Re: [PATCH v4 2/4] git-submodule init: Record submodule.<name>.branch in repository config.
From: Jens Lehmann @ 2012-11-27 23:19 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Phil Hord,
Shawn Pearce, Nahor
In-Reply-To: <6734714e90064b3932126565e3027d7edcf45d51.1353962698.git.wking@tremily.us>
Am 26.11.2012 22:00, schrieb W. Trevor King:
> From: "W. Trevor King" <wking@tremily.us>
>
> This allows users to override the .gitmodules value with a
> per-repository value.
Your intentions makes lots of sense, but your patch does more than
that. Copying the branch setting into .git/config sets the initial
branch setting into stone. That makes it impossible to have a branch
"foo" in the superproject using a branch "bar" in a submodule and
another superproject branch "frotz" using branch "nitfol" for the
same submodule. You should use the branch setting from .git/config
if present and fall back to the branch setting from .gitmodules if
not, which would enable the user to have her own setting if she
doesn't like what upstream provides but would still enable others
to follow different submodule branches in different superproject
branches.
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/config.txt | 9 +++++----
> git-submodule.sh | 7 +++++++
> t/t7400-submodule-basic.sh | 18 ++++++++++++++++++
> 3 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 11f320b..1304499 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1994,10 +1994,11 @@ status.submodulesummary::
> submodule.<name>.path::
> submodule.<name>.url::
> submodule.<name>.update::
> - The path within this project, URL, and the updating strategy
> - for a submodule. These variables are initially populated
> - by 'git submodule init'; edit them to override the
> - URL and other values found in the `.gitmodules` file. See
> +submodule.<name>.branch::
> + The path within this project, URL, the updating strategy, and the
> + local branch name for a submodule. These variables are initially
> + populated by 'git submodule init'; edit them to override the URL and
> + other values found in the `.gitmodules` file. See
> linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
>
> submodule.<name>.fetchRecurseSubmodules::
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 6eed008..c51b6ae 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -505,6 +505,13 @@ cmd_init()
> test -n "$(git config submodule."$name".update)" ||
> git config submodule."$name".update "$upd" ||
> die "$(eval_gettext "Failed to register update mode for submodule path '\$sm_path'")"
> +
> + # Copy "branch" setting when it is not set yet
> + branch="$(git config -f .gitmodules submodule."$name".branch)"
> + test -z "$branch" ||
> + test -n "$(git config submodule."$name".branch)" ||
> + git config submodule."$name".branch "$branch" ||
> + die "$(eval_gettext "Failed to register branch for submodule path '\$sm_path'")"
> done
> }
>
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index fc08647..3dc8237 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch=<name> --branch' '
> )
> '
>
> +test_expect_success 'init should register submodule branch in .git/config' '
> + (
> + cd addtest &&
> + git submodule init &&
> + test "$(git config submodule.submod-follow.branch)" = "final"
> + )
> +'
> +
> +test_expect_success 'local config should override .gitmodules branch' '
> + (
> + cd addtest &&
> + rm -fr submod-follow &&
> + git config submodule.submod-follow.branch initial
> + git submodule init &&
> + test "$(git config submodule.submod-follow.branch)" = "initial"
> + )
> +'
> +
> test_expect_success 'setup - add an example entry to .gitmodules' '
> GIT_CONFIG=.gitmodules \
> git config submodule.example.url git://example.com/init.git
>
^ permalink raw reply
* [PATCH v2 0/3] Add option to change order of parents in merge commit
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab
The second version of patches introducing option to change order
of parents in merge commits. The changes in respect to the previous
version:
- I have divided the changes to the preparatory ones, which
only refactore the code without introducing new functionality, and
the commit which introduces the new option
- The documentation for the new options has been added
This is not yet a final version, as the tests are missing. But maybe while I'm working
on them there will be some comments.
Kacper Kornet (3):
Process MERGE_MODE before MERGE_HEAD
Allow for MERGE_MODE to specify more then one mode
Add option to transpose parents of merge commit
Documentation/merge-options.txt | 7 +++++++
builtin/commit.c | 22 ++++++++++++++--------
builtin/merge.c | 16 ++++++++++++----
commit.c | 11 +++++++++++
commit.h | 2 ++
git-pull.sh | 4 +++-
6 files changed, 49 insertions(+), 13 deletions(-)
--
1.8.0.1
^ permalink raw reply
* [PATCH v2 1/3] Process MERGE_MODE before MERGE_HEAD
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab, Kacper Kornet
In-Reply-To: <1354057217-65886-1-git-send-email-draenog@pld-linux.org>
It is in preparation to introduce --transpose-parents option to
git-merge, when the content of MERGE_MODE will dictate how the
MERGE_HEAD is interpreted.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---
builtin/commit.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..273332f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1481,6 +1481,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!reflog_msg)
reflog_msg = "commit (merge)";
+ if (!stat(git_path("MERGE_MODE"), &statbuf)) {
+ if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
+ die_errno(_("could not read MERGE_MODE"));
+ if (!strcmp(sb.buf, "no-ff"))
+ allow_fast_forward = 0;
+ }
pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
@@ -1496,12 +1502,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
fclose(fp);
strbuf_release(&m);
- if (!stat(git_path("MERGE_MODE"), &statbuf)) {
- if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
- die_errno(_("could not read MERGE_MODE"));
- if (!strcmp(sb.buf, "no-ff"))
- allow_fast_forward = 0;
- }
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
--
1.8.0.1
^ permalink raw reply related
* [PATCH v2 3/3] Add option to transpose parents of merge commit
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab, Kacper Kornet
In-Reply-To: <1354057217-65886-1-git-send-email-draenog@pld-linux.org>
When the changes are pushed upstream, and in the meantime someone else
updated upstream branch git advises to use git pull. This results in
history:
---A---B---C--
\ /
D---E
where B is the local commit. D, E are commits pushed by someone else
when the developer was working on B. However sometimes the following
history is preferable:
---A---D---C'--
\ /
'-B-'
The difference between C and C' is the order of parents. This change
allow for easier way to obtain this effect by introducing the option
--transpose-parents to git-merge and git-pull, which changes the order
of parents in resulting commit moving the original first parent to
the very end of list of parents.
The transposition is done just before the commit is finalized, so the
meaning of "our" and "their" for conflict resolution is not changed, so
"ours" denotes local version and "theirs" upstream.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---
Documentation/merge-options.txt | 7 +++++++
builtin/commit.c | 8 +++++++-
builtin/merge.c | 16 ++++++++++++----
commit.c | 11 +++++++++++
commit.h | 2 ++
git-pull.sh | 4 +++-
6 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0bcbe0a..b4fbfdc 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -88,6 +88,13 @@ option can be used to override --squash.
Synonyms to --stat and --no-stat; these are deprecated and will be
removed in the future.
+--transpose-parents::
+ Transpose the parents in the final commit. The change is made
+ just before the commit so the meaning of 'our' and 'their'
+ concepts remains the same (i.e. 'our' means current branch before
+ the merge).
+
+
ifndef::git-pull[]
-q::
--quiet::
diff --git a/builtin/commit.c b/builtin/commit.c
index ee0e884..ab2b844 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1477,6 +1477,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
FILE *fp;
+ int reversed_order=0;
if (!reflog_msg)
reflog_msg = "commit (merge)";
@@ -1484,10 +1485,13 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
while (strbuf_getline(&m, fp, '\n') != EOF) {
if (!strcmp(m.buf, "no-ff"))
allow_fast_forward = 0;
+ if (!strcmp(m.buf, "reversed-order"))
+ reversed_order = 1;
}
fclose(fp);
}
- pptr = &commit_list_insert(current_head, pptr)->next;
+ if (!reversed_order)
+ pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1502,6 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
fclose(fp);
strbuf_release(&m);
+ if (reversed_order)
+ pptr = &commit_list_insert(current_head, pptr)->next;
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..41738a5 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
static int show_progress = -1;
static int default_to_upstream;
static const char *sign_commit;
+static int reversed_order=0;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key id"),
N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
OPT_BOOLEAN(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
+ OPT_BOOLEAN(0, "transpose-parents", &reversed_order, N_("reverse order of parents")),
OPT_END()
};
@@ -822,9 +824,9 @@ static int merge_trivial(struct commit *head, struct commit_list *remoteheads)
write_tree_trivial(result_tree);
printf(_("Wonderful.\n"));
- parent->item = head;
+ parent->item = reversed_order ? remoteheads->item : head;
parent->next = xmalloc(sizeof(*parent->next));
- parent->next->item = remoteheads->item;
+ parent->next->item = reversed_order ? head : remoteheads->item;
parent->next->next = NULL;
prepare_to_commit(remoteheads);
if (commit_tree(&merge_msg, result_tree, parent, result_commit, NULL,
@@ -848,8 +850,12 @@ static int finish_automerge(struct commit *head,
free_commit_list(common);
parents = remoteheads;
- if (!head_subsumed || !allow_fast_forward)
+ if (!head_subsumed || !allow_fast_forward) {
+ if (reversed_order )
+ commit_list_insert_end(head, &parents);
+ else
commit_list_insert(head, &parents);
+ }
strbuf_addch(&merge_msg, '\n');
prepare_to_commit(remoteheads);
if (commit_tree(&merge_msg, result_tree, parents, result_commit,
@@ -994,7 +1000,9 @@ static void write_merge_state(struct commit_list *remoteheads)
die_errno(_("Could not open '%s' for writing"), filename);
strbuf_reset(&buf);
if (!allow_fast_forward)
- strbuf_addf(&buf, "no-ff");
+ strbuf_addf(&buf, "no-ff\n");
+ if (reversed_order)
+ strbuf_addf(&buf, "reversed-order\n");
if (write_in_full(fd, buf.buf, buf.len) != buf.len)
die_errno(_("Could not write to '%s'"), filename);
close(fd);
diff --git a/commit.c b/commit.c
index e8eb0ae..6e58994 100644
--- a/commit.c
+++ b/commit.c
@@ -363,6 +363,17 @@ struct commit_list *commit_list_insert(struct commit *item, struct commit_list *
return new_list;
}
+struct commit_list *commit_list_insert_end(struct commit *item, struct commit_list **list_p)
+{
+ struct commit_list *list_iter = *list_p;
+ while(list_iter->next)
+ list_iter = list_iter->next;
+ list_iter->next = xmalloc(sizeof(*list_iter->next));
+ list_iter->next->item = item;
+ list_iter->next->next = NULL;
+ return *list_p;
+}
+
unsigned commit_list_count(const struct commit_list *l)
{
unsigned c = 0;
diff --git a/commit.h b/commit.h
index b6ad8f3..17ae5e5 100644
--- a/commit.h
+++ b/commit.h
@@ -53,6 +53,8 @@ int find_commit_subject(const char *commit_buffer, const char **subject);
struct commit_list *commit_list_insert(struct commit *item,
struct commit_list **list);
+struct commit_list *commit_list_insert_end(struct commit *item,
+ struct commit_list **list);
struct commit_list **commit_list_append(struct commit *commit,
struct commit_list **next);
unsigned commit_list_count(const struct commit_list *l);
diff --git a/git-pull.sh b/git-pull.sh
index 266e682..d9c7591 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -84,6 +84,8 @@ do
no_ff=--no-ff ;;
--ff-only)
ff_only=--ff-only ;;
+ --transpose-parents)
+ transpose_parents=--transpose-parents;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -283,7 +285,7 @@ true)
eval="$eval --onto $merge_head ${oldremoteref:-$merge_head}"
;;
*)
- eval="git-merge $diffstat $no_commit $edit $squash $no_ff $ff_only"
+ eval="git-merge $diffstat $no_commit $edit $squash $no_ff $ff_only $transpose_parents"
eval="$eval $log_arg $strategy_args $merge_args $verbosity $progress"
eval="$eval \"\$merge_name\" HEAD $merge_head"
;;
--
1.8.0.1
^ permalink raw reply related
* [PATCH v2 2/3] Allow for MERGE_MODE to specify more then one mode
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab, Kacper Kornet
In-Reply-To: <1354057217-65886-1-git-send-email-draenog@pld-linux.org>
Presently only one merge mode exists: non-fast-forward. But in future
the second one (transpose-parents) will be added, so the need to read
all lines of MERGE_MODE.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---
builtin/commit.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 273332f..ee0e884 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1427,7 +1427,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
- struct stat statbuf;
int allow_fast_forward = 1;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1481,11 +1480,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!reflog_msg)
reflog_msg = "commit (merge)";
- if (!stat(git_path("MERGE_MODE"), &statbuf)) {
- if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
- die_errno(_("could not read MERGE_MODE"));
- if (!strcmp(sb.buf, "no-ff"))
- allow_fast_forward = 0;
+ if((fp = fopen(git_path("MERGE_MODE"), "r"))) {
+ while (strbuf_getline(&m, fp, '\n') != EOF) {
+ if (!strcmp(m.buf, "no-ff"))
+ allow_fast_forward = 0;
+ }
+ fclose(fp);
}
pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
--
1.8.0.1
^ permalink raw reply related
* Re: Possible vulnerability to SHA-1 collisions
From: Jeff King @ 2012-11-27 23:07 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Michael Hirshleifer, git
In-Reply-To: <CAJo=hJsZdduMdSbN+3Ei-7vx3_Q7tO88LywWj5Vw3Ngs0QgsZg@mail.gmail.com>
On Sat, Nov 24, 2012 at 10:09:31AM -0800, Shawn O. Pearce wrote:
> On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer <111mth@caltech.edu> wrote:
> > Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
> > checksum (including Git header). Mr. Evil creates a local branch with an
> > innocuous name like “test-bugfix”, and adds a commit containing a reference
> > to the evil file. Separately, using a sockpuppet, Evil Guy creates an
> > innocuous bugfix (very likely to be accepted) containing the innocuous file,
> > and submits it to Good Guy. Before Good Guy can commit the bugfix, Evil Guy
> > pushes the evil branch to Github, and then immediately deletes it; or
> > equivalently --force pushes any innocuous commit on top of it. (This is
> > unlikely to arouse suspicion, and he can always say he deleted it because it
> > didn’t work.)
>
> Here you assume Evil Guy has write access to the same repository as
> Good Guy. Lets assume this is possible, e.g. Evil Guy is actually
> impersonating White Hat because he managed to steal White Hat's
> credentials through a compromised host. Typically Evil Guy doesn't
> have write access to Good Guy's repository, and thus can't introduce
> objects into it without Good Guy being the one that creates the
> objects.
>
> But lets just keep he assumption that Evil Guy can write to the same
> repository as Good Guy, and that he managed to create the bad branch
> and delete it, leaving the bad object in an unreachable state for 2
> weeks.
Actually, it is somewhat easier on GitHub, because we share objects
between forks of a repository via the alternates mechanism. So if you
can publicly fork the project and push a branch to your fork, you can
write to the shared object database. This applies not just to GitHub,
but to any hosting service which shares object databases between
projects (I do not know offhand if other hosting providers like Google
Code do this).
But as you noted later in your email, the byte-for-byte comparison on
object collision will let us detect this case when the good guy tries to
push and abort.
-Peff
PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
easier said than done. We do not have SHA-1 collisions yet, but if
the md5 attacks are any indication, the innocuous file will not be
completely clean; it will need to have some embedded binary goo that
is mutated randomly during the collision process (which is why the
md5 attacks were demonstrated with postscript files which _rendered_
to look good, but contained a chunk of random bytes in a spot ignored
by the postscript interpreter).
^ permalink raw reply
* Re: [PATCH 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections
From: Max Horn @ 2012-11-27 23:06 UTC (permalink / raw)
Cc: git
In-Reply-To: <1354057407-83151-8-git-send-email-max@quendi.de>
Ouch. This one should *not* have been sent (the "[PATCH v2 6/6]" one is the correct one). Very sorry :(. I'll triple check next time.
Max
On 28.11.2012, at 00:03, Max Horn wrote:
> The documentation was misleading in that it gave the impression that
> 'for-push' could be used as a ref attribute in the output of the
> 'list' command. That is wrong.
>
> Also, explicitly point out the connection between the commands
> 'list' and 'options' on the one hand, and the sections
> 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
>
> Signed-off-by: Max Horn <max@quendi.de>
> ---
> Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index 023dcca..e1df01d 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -227,6 +227,8 @@ Support for this command is mandatory.
> the name; unrecognized attributes are ignored. The list ends
> with a blank line.
> +
> +See REF LIST ATTRIBUTES for a list of currently defined options.
> ++
> Supported if the helper has the "fetch" or "import" capability.
>
> 'list for-push'::
> @@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
> for it). Options should be set before other commands,
> and may influence the behavior of those commands.
> +
> +See OPTIONS for a list of currently defined options.
> ++
> Supported if the helper has the "option" capability.
>
> 'fetch' <sha1> <name>::
> @@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
> per line, terminated with a blank line.
> Outputs a single blank line when all fetch commands in the
> same batch are complete. Only objects which were reported
> - in the ref list with a sha1 may be fetched this way.
> + in the output of 'list' with a sha1 may be fetched this way.
> +
> Optionally may output a 'lock <file>' line indicating a file under
> GIT_DIR/objects/pack which is keeping a pack until refs can be
> @@ -360,10 +364,9 @@ capabilities reported by the helper.
> REF LIST ATTRIBUTES
> -------------------
>
> -'for-push'::
> - The caller wants to use the ref list to prepare push
> - commands. A helper might chose to acquire the ref list by
> - opening a different type of connection to the destination.
> +The 'list' command produces a list of refs in which each ref
> +may be followed by a list of attributes. The following ref list
> +attributes are defined.
>
> 'unchanged'::
> This ref is unchanged since the last import or fetch, although
> @@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
>
> OPTIONS
> -------
> +
> +The following options are defined and (under suitable circumstances)
> +set by git if the remote helper has the 'option' capability.
> +
> 'option verbosity' <n>::
> Changes the verbosity of messages displayed by the helper.
> A value of 0 for <n> means that processes operate
> --
> 1.8.0.393.gcc9701d
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-27 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vzk22lmz9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
> the author and committer ident (i.e. the timestamp has to be
> integral number of seconds since the epoch, not before it, nor
> with fractional seconds).
Is this architecturally significant? It sounds like another
implementation detail.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH v2 3/6] git-remote-helpers.txt: minor grammar fix
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index db63541..7eb43d7 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line.
'capabilities'::
Lists the capabilities of the helper, one per line, ending
with a blank line. Each capability may be preceded with '*',
- which marks them mandatory for git version using the remote
- helper to understand (unknown mandatory capability is fatal
- error).
+ which marks them mandatory for git versions using the remote
+ helper to understand. Any unknown mandatory capability is a
+ fatal error.
'list'::
Lists the refs, one per line, in the format "<value> <name>
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 6/6] git-remote-helpers.txt: clarify options & ref list attributes
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
Supported if the helper has the "fetch" or "import" capability.
'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
for it). Options should be set before other commands,
and may influence the behavior of those commands.
+
+See OPTIONS for a list of currently defined options.
++
Supported if the helper has the "option" capability.
'fetch' <sha1> <name>::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ in the output of 'list' with a sha1 may be fetched this way.
+
Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
REF LIST ATTRIBUTES
-------------------
-'for-push'::
- The caller wants to use the ref list to prepare push
- commands. A helper might chose to acquire the ref list by
- opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
OPTIONS
-------
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
'option verbosity' <n>::
Changes the verbosity of messages displayed by the helper.
A value of 0 for <n> means that processes operate
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 4/6] git-remote-helpers.txt: rearrange description of capabilities
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 134 +++++++++++++++--------------------
1 file changed, 56 insertions(+), 78 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 7eb43d7..7ac1461 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of commands.
The operations a helper supports are declared to git in the response
to the `capabilities` command (see COMMANDS, below).
-'option'::
- For specifying settings like `verbosity` (how much output to
- write to stderr) and `depth` (how much history is wanted in the
- case of a shallow clone) that affect how other commands are
- carried out.
-
-'connect'::
- For fetching and pushing using git's native packfile protocol
- that requires a bidirectional, full-duplex connection.
-
-'push'::
- For listing remote refs and pushing specified objects from the
- local object store to remote refs.
-
-'fetch'::
- For listing remote refs and fetching the associated history to
- the local object store.
-
-'export'::
- For listing remote refs and pushing specified objects from a
- fast-import stream to remote refs.
-
-'import'::
- For listing remote refs and fetching the associated history as
- a fast-import stream.
-
-'refspec' <refspec>::
- This modifies the 'import' capability, allowing the produced
- fast-import stream to modify refs in a private namespace
- instead of writing to refs/heads or refs/remotes directly.
- It is recommended that all importers providing the 'import'
- capability use this.
-+
-A helper advertising the capability
-`refspec refs/heads/*:refs/svn/origin/branches/*`
-is saying that, when it is asked to `import refs/heads/topic`, the
-stream it outputs will update the `refs/svn/origin/branches/topic`
-ref.
-+
-This capability can be advertised multiple times. The first
-applicable refspec takes precedence. The left-hand of refspecs
-advertised with this capability must cover all refs reported by
-the list command. If no 'refspec' capability is advertised,
-there is an implied `refspec *:*`.
-
-'bidi-import'::
- The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
- to retrieve information about blobs and trees that already exist in
- fast-import's memory. This requires a channel from fast-import to the
- remote-helper.
- If it is advertised in addition to "import", git establishes a pipe from
- fast-import to the remote-helper's stdin.
- It follows that git and fast-import are both connected to the
- remote-helper's stdin. Because git can send multiple commands to
- the remote-helper it is required that helpers that use 'bidi-import'
- buffer all 'import' commands of a batch before sending data to fast-import.
- This is to prevent mixing commands and fast-import responses on the
- helper's stdin.
-
-'export-marks' <file>::
- This modifies the 'export' capability, instructing git to dump the
- internal marks table to <file> when complete. For details,
- read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
-
-'import-marks' <file>::
- This modifies the 'export' capability, instructing git to load the
- marks specified in <file> before processing any input. For details,
- read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+In the following, we list all defined capabilities and for
+each we list which commands a helper with that capability
+must provide.
Capabilities for Pushing
-~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^
'connect'::
Can attempt to connect to 'git receive-pack' (for pushing),
- 'git upload-pack', etc for communication using the
- packfile protocol.
+ 'git upload-pack', etc for communication using
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
+
Supported commands: 'connect'.
@@ -186,11 +122,12 @@ Other frontends may have some other order of preference.
Capabilities for Fetching
-~~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^^
'connect'::
Can try to connect to 'git upload-pack' (for fetching),
'git receive-pack', etc for communication using the
- packfile protocol.
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
+
Supported commands: 'connect'.
@@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS).
When choosing between 'fetch' and 'import', git prefers 'fetch'.
Other frontends may have some other order of preference.
+Miscellaneous capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+'option'::
+ For specifying settings like `verbosity` (how much output to
+ write to stderr) and `depth` (how much history is wanted in the
+ case of a shallow clone) that affect how other commands are
+ carried out.
+
'refspec' <refspec>::
- This modifies the 'import' capability.
+ This modifies the 'import' capability, allowing the produced
+ fast-import stream to modify refs in a private namespace
+ instead of writing to refs/heads or refs/remotes directly.
+ It is recommended that all importers providing the 'import'
+ capability use this.
+
-A helper advertising
+A helper advertising the capability
`refspec refs/heads/*:refs/svn/origin/branches/*`
-in its capabilities is saying that, when it handles
-`import refs/heads/topic`, the stream it outputs will update the
-`refs/svn/origin/branches/topic` ref.
+is saying that, when it is asked to `import refs/heads/topic`, the
+stream it outputs will update the `refs/svn/origin/branches/topic`
+ref.
+
This capability can be advertised multiple times. The first
applicable refspec takes precedence. The left-hand of refspecs
@@ -227,6 +177,34 @@ advertised with this capability must cover all refs reported by
the list command. If no 'refspec' capability is advertised,
there is an implied `refspec *:*`.
+'bidi-import'::
+ This modifies the 'import' capability.
+ The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
+ to retrieve information about blobs and trees that already exist in
+ fast-import's memory. This requires a channel from fast-import to the
+ remote-helper.
+ If it is advertised in addition to "import", git establishes a pipe from
+ fast-import to the remote-helper's stdin.
+ It follows that git and fast-import are both connected to the
+ remote-helper's stdin. Because git can send multiple commands to
+ the remote-helper it is required that helpers that use 'bidi-import'
+ buffer all 'import' commands of a batch before sending data to fast-import.
+ This is to prevent mixing commands and fast-import responses on the
+ helper's stdin.
+
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+
+
+
+
COMMANDS
--------
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
Supported if the helper has the "fetch" or "import" capability.
'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
for it). Options should be set before other commands,
and may influence the behavior of those commands.
+
+See OPTIONS for a list of currently defined options.
++
Supported if the helper has the "option" capability.
'fetch' <sha1> <name>::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ in the output of 'list' with a sha1 may be fetched this way.
+
Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
REF LIST ATTRIBUTES
-------------------
-'for-push'::
- The caller wants to use the ref list to prepare push
- commands. A helper might chose to acquire the ref list by
- opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
OPTIONS
-------
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
'option verbosity' <n>::
Changes the verbosity of messages displayed by the helper.
A value of 0 for <n> means that processes operate
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 0/6] Improve remote helper documentation
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
Various remote helper capabilities and commands were not
documented, in particular 'export', or documented in a misleading
way (e.g. 'for-push' was listed as a ref attribute understood by
git, which is not the case). This patch series changes that, and
also address some other things in the remote helper documentation
that I found jarring when reading through it.
Note that the description of export and (im|ex)port-marks probably can be
improved, and I hope that somebody who knows more about them
than me and/or is better at writing documentation will do just that.
But I felt it was better to provide something than to do nothing
and only complain, as I did previously on this subject ;-).
Max Horn (6):
git-remote-helpers.txt: document invocation before input format
git-remote-helpers.txt: document missing capabilities
git-remote-helpers.txt: minor grammar fix
git-remote-helpers.txt: rearrange description of capabilities
git-remote-helpers.txt: clarify command <-> capability correspondences
git-remote-helpers.txt: clarify options & ref list attributes
Documentation/git-remote-helpers.txt | 245 ++++++++++++++++++++---------------
1 file changed, 140 insertions(+), 105 deletions(-)
--
1.8.0.393.gcc9701d
^ permalink raw reply
* [PATCH v2 5/6] git-remote-helpers.txt: clarify command <-> capability correspondences
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
In particular, document 'list for-push' separately from 'list', as
the former needs only be supported for the push/export
capabilities, and the latter only for fetch/import. Indeed, a
hypothetically 'push-only' helper would only need to support the
former, not the latter.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 7ac1461..023dcca 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard input, one per line.
which marks them mandatory for git versions using the remote
helper to understand. Any unknown mandatory capability is a
fatal error.
++
+Support for this command is mandatory.
'list'::
Lists the refs, one per line, in the format "<value> <name>
@@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard input, one per line.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
-If 'push' is supported this may be called as 'list for-push'
-to obtain the current refs prior to sending one or more 'push'
-commands to the helper.
+Supported if the helper has the "fetch" or "import" capability.
+
+'list for-push'::
+ Similar to 'list', except that it is used if and only if
+ the caller wants to the resulting ref list to prepare
+ push commands.
+ A helper supporting both push and fetch can use this
+ to distinguish for which operation the output of 'list'
+ is going to be used, possibly reducing the amount
+ of work that needs to be performed.
++
+Supported if the helper has the "push" or "export" capability.
'option' <name> <value>::
Sets the transport helper option <name> to <value>. Outputs a
@@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to fast-import
to prevent mixing of commands and fast-import responses on the helper's
stdin.
+
-Supported if the helper has the 'import' capability.
+Supported if the helper has the "import" capability.
'export'::
Instructs the remote helper that any subsequent input is
@@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks for
local objects. This can be used to implement for incremental
operations.
+
-Supported if the helper has the 'export' capability.
+Supported if the helper has the "export" capability.
'connect' <service>::
Connects to given service. Standard input and standard output
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 2/6] git-remote-helpers.txt: document missing capabilities
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
Specifically, document the 'export' and '(im|ex)port-marks'
capabilities as well as the export command, which were
undocumented (but in active use).
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 45 +++++++++++++++++++++++++++++++++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 9a7e583..db63541 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below).
For listing remote refs and fetching the associated history to
the local object store.
+'export'::
+ For listing remote refs and pushing specified objects from a
+ fast-import stream to remote refs.
+
'import'::
For listing remote refs and fetching the associated history as
a fast-import stream.
@@ -143,6 +147,16 @@ there is an implied `refspec *:*`.
This is to prevent mixing commands and fast-import responses on the
helper's stdin.
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+
Capabilities for Pushing
~~~~~~~~~~~~~~~~~~~~~~~~
'connect'::
@@ -158,9 +172,18 @@ Supported commands: 'connect'.
+
Supported commands: 'list for-push', 'push'.
-If a helper advertises both 'connect' and 'push', git will use
-'connect' if possible and fall back to 'push' if the helper requests
-so when connecting (see the 'connect' command under COMMANDS).
+'export'::
+ Can discover remote refs and push specified objects from a
+ fast-import stream to remote refs.
++
+Supported commands: 'list for-push', 'export'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'push' and 'export', git prefers 'push'.
+Other frontends may have some other order of preference.
+
Capabilities for Fetching
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -307,6 +330,22 @@ stdin.
+
Supported if the helper has the 'import' capability.
+'export'::
+ Instructs the remote helper that any subsequent input is
+ part of a fast-import stream (generated by 'git fast-export')
+ containing objects which should be pushed to the remote.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+The 'export-marks' and 'import-marks' capabilities, if specified,
+affect this command in so far as they are passed on to 'git
+fast-export', which then will load/store a table of marks for
+local objects. This can be used to implement for incremental
+operations.
++
+Supported if the helper has the 'export' capability.
+
'connect' <service>::
Connects to given service. Standard input and standard output
of helper are connected to specified service (git prefix is
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 62 ++++++++++++++++++------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 5ce4cda..9a7e583 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
'fetch', 'option', and 'push'.
+INVOCATION
+----------
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'<transport>://<address>', but any arbitrary string is possible.
+The 'GIT_DIR' environment variable is set up for the remote helper
+and can be used to determine where to store additional data or from
+which directory to invoke auxiliary git commands.
+
+When git encounters a URL of the form '<transport>://<address>', where
+'<transport>' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-<transport>' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '<transport>::<address>' explicitly instructs git to
+invoke 'git remote-<transport>' with '<address>' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '<address>', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has 'remote.<name>.vcs' set to
+'<transport>', git explicitly invokes 'git remote-<transport>' with
+'<name>' as the first argument. If set, the second argument is
+'remote.<name>.url'; otherwise, the second argument is omitted.
+
INPUT FORMAT
------------
@@ -173,37 +204,6 @@ advertised with this capability must cover all refs reported by
the list command. If no 'refspec' capability is advertised,
there is an implied `refspec *:*`.
-INVOCATION
-----------
-
-Remote helper programs are invoked with one or (optionally) two
-arguments. The first argument specifies a remote repository as in git;
-it is either the name of a configured remote or a URL. The second
-argument specifies a URL; it is usually of the form
-'<transport>://<address>', but any arbitrary string is possible.
-The 'GIT_DIR' environment variable is set up for the remote helper
-and can be used to determine where to store additional data or from
-which directory to invoke auxiliary git commands.
-
-When git encounters a URL of the form '<transport>://<address>', where
-'<transport>' is a protocol that it cannot handle natively, it
-automatically invokes 'git remote-<transport>' with the full URL as
-the second argument. If such a URL is encountered directly on the
-command line, the first argument is the same as the second, and if it
-is encountered in a configured remote, the first argument is the name
-of that remote.
-
-A URL of the form '<transport>::<address>' explicitly instructs git to
-invoke 'git remote-<transport>' with '<address>' as the second
-argument. If such a URL is encountered directly on the command line,
-the first argument is '<address>', and if it is encountered in a
-configured remote, the first argument is the name of that remote.
-
-Additionally, when a configured remote has 'remote.<name>.vcs' set to
-'<transport>', git explicitly invokes 'git remote-<transport>' with
-'<name>' as the first argument. If set, the second argument is
-'remote.<name>.url'; otherwise, the second argument is omitted.
-
COMMANDS
--------
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 6/5] diff --shortstat: do not count "unmerged" entries
From: Junio C Hamano @ 2012-11-27 22:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
Fix the same issue as the previous one for "git diff --stat";
unmerged entries was doubly-counted.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 26ede82..374b235 100644
--- a/diff.c
+++ b/diff.c
@@ -1701,9 +1701,8 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
int added = data->files[i]->added;
int deleted= data->files[i]->deleted;
- if (data->files[i]->is_unmerged)
- continue;
- if (!data->files[i]->is_interesting && (added + deleted == 0)) {
+ if (data->files[i]->is_unmerged ||
+ (!data->files[i]->is_interesting && (added + deleted == 0))) {
total_files--;
} else if (!data->files[i]->is_binary) { /* don't count bytes */
adds += added;
--
1.8.0.1.337.gd2c5e06
^ permalink raw reply related
* Re: Millisecond precision in timestamps?
From: Junio C Hamano @ 2012-11-27 22:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eric S. Raymond, git
In-Reply-To: <CAJo=hJtZ+n+D4pOmeNApDeLNyZYeqnEDDYJWwSj_wLauQ+w4hQ@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> JGit would fortunately ignore a floating point timestamp specification
> if given in a commit, but I don't know about other Git
> implementations... like say git. :-)
fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
the author and committer ident (i.e. the timestamp has to be
integral number of seconds since the epoch, not before it, nor
with fractional seconds).
^ permalink raw reply
* Re: [PATCH 3/6] Fix grammar
From: Junio C Hamano @ 2012-11-27 22:02 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <5F2BC41E-6F77-44B8-B05E-8FB07E82EFA3@quendi.de>
Max Horn <max@quendi.de> writes:
> If this is indeed it, would a commit message like
>
> git-remote-helper.txt: minor grammar fix
Perfect. Thanks.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Guillaume DE BURE @ 2012-11-27 22:01 UTC (permalink / raw)
To: David Aguilar
Cc: Sitaram Chamarty, Felipe Contreras, esr, Nguyen Thai Ngoc Duy,
git, msysGit
In-Reply-To: <CAJDDKr7r5iP_LpXAT9Xz35GOfbDuDxSAKUvx=4dxa2LE_GLgrA@mail.gmail.com>
Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sitaramc@gmail.com>
wrote:
> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:
> >> *cough* git-cola *cough*
> >>
> >> it runs everywhere. Yes, windows too. It's written in python.
> >> It's been actively maintained since 2007.
> >>
> >> It's "modern" and has features that don't exist anywhere else.
> >>
> >> It even has tests. It even comes with a building full of willing
> >> guinea-pigs^Wtesters that let me know right away when
> >> anything goes wrong.
> >>
> >> It uses Qt but that's really the whole point of Qt -> cross-platform.
> >> (not sure how that wiki page ended up saying Gnome/GTK?)
> >>
> >> The DAG aka git-dag (in its master branch, about to be released)
> >> is nicer looking then gitk IMO. gitk still has some features
> >> that are better too--there's no silver bullet, but the delta
> >> is pretty small.
> >
> > Gitk does a lot of things that people don't realise, since they're not
> > really documented and you have to scrounge around on the UI. The
> > thing is, it's just about the most awesome tool for code archeology I
> > have seen.
> >
> > I realise (from looking at the doc page) that git-cola helps you do
> > all sorts of things, but those are all things I am happier doing at
> > the command line.
>
> Ditto. There's actually a few small things I use it for,
> mainly for teasing apart commits. These days you can use git-gui
> for that, but in the old days it was the only way to interactively
> select individual lines and stage/unstage/revert them, etc.
> I don't think we can line-by-line revert in git-gui yet, though.
>
> Some other small things that I use: ctrl-g, type something
> for grep, hit enter twice and I'm in my editor on that
> (or any other selected) line. 'spacebar' does xdg-open,
> and 'enter' launches the editor in the status widget;
> small things. I, too, do most stuff on the command line.
>
> The grep thing is a good example. You have tons of output,
> you see the one line that you care about, and you want to jump
> there. Clicking on that line and hitting enter is the minimal
> effort to do that. You don't have to click because we also
> have keyboard navigation. I have a feeling that there's probably
> something I'm missing, though.. another way of working (emacs?)
> that would render all of this custom GUI stuff pointless.
>
> What I learned about users:
>
> The commit editor is the #1 thing that got my coworkers finally
> writing better commit messages. It forces the subject/description
> separation and shows yellow, red when the subject gets too long.
> It also auto-wraps. IMO it makes sense for git-gui to do
> the same these days.
>
> > Gitk does precisely those things which *require* a GUI, where the
> > amount of information presented overwhelms a text interface. The
> > display is concisely designed to give you the maximum information at a
> > minimum space use. For example, a little black square when a commit
> > has a note attached. Even hovering over the arrow-heads, on complex
> > trees where the line gets broken, does something meaningful.
> >
> > if I had to pin it down, the feature I use most often is "Show origin
> > of this line". Other features I use often are
> >
> > - review a commit file by file (f and b keys, also spacebar and 'd')
> > - search by SHA1 (4 digits appear to be enough, regardless of how
> >
> > big your repo is),
> >
> > - search for commits changing path/dir (while still showing all the
> >
> > commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
> > search up and down for commits touching README.txt
> >
> > - and navigating the commit tree looking for stuff
> >
> > http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
> > document some of the stuff I have found and use.
>
> Wow, this is awesome.
>
> > One final point: the DAG on the right wastes enormous amounts of
> > space. Purely subjectively, it is almost jarring on the senses. (If
> > you reduce it, it becomes unreadable).
> >
> > With all due respect, git-cola/dag isn't anywhere near what gitk does,
> > at least for people who are not afraid of the command line and only
> > need the GUI to visualise a truly complex tree.
>
> This is really great feedback.
> cc:ing Guillaume since he had similar ideas.
>
> thx,
Thanks David for cc:ing me. I'm sorry I was quite below the radar lately, had
too much work to get back on the dag. What I would really like for the dag is
to become as useful as the treeview in git extensions
(http://code.google.com/p/gitextensions/), where it is the central place for
checkout, merge, cherry picks...
My only complaint with git extensions is that it is poorly integrated on my
linux desktop, due to framework choice (let's not start a flame war here, it's
not the point). On the other hand, git-cola is quite easy to hack on thanks to
its python roots, well integrated on all OS thanks to Qt, so I thought it
would be great to make it at least on par.
Had an opportunity to rework the visuals on the dag, but not yet its
functionalities... As soon as I'm back on normal life, I'll pickup the subject
again :)
Cheers,
Guillaume
--
Skrooge, a free, Open Source, personal finances software for linux, Mac OS,
Windows
http://skrooge.org
^ 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