* RE: Millisecond precision in timestamps?
From: Pyeron, Jason J CTR (US) @ 2012-11-27 21:44 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <20121127204828.577264065F@snark.thyrsus.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
> -----Original Message-----
> From: Eric S. Raymond
> Sent: Tuesday, November 27, 2012 3:48 PM
>
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
>
> In general, git metadata can carry forward almost all the metadata in
> a Subversion repository. Among the handful of minor exceptions (empty
> directories, flow structure, certain kinds of mergeinfos) there is one
> that stands out because it seems to be an implementation detail rather
> than a consequence of fundamentally different design decisions.
>
> I refer to the one-second precision of git timestamps. Subversion
> stores its commit and property-change timestamps to microsecond
> precision; conversion tools have to throw the subsecond part of
> this information away.
>
> Has going to timestamps with the full precision of the system clock
> been considered and rejected, or am I the first to bring this up?
>
> If I were to write refactoring patches that treated "timestamp" as
> an ADT, with a view towards hiding the difference between int and
> float timestamps and eventually experimenting with float ones,
Do you really mean floating point numbers with approximate imprecise values?
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ 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
* 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: 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
* [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
* [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 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 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 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 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 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 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 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
* 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
* 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: 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
* [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
* [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 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 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
* 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] 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: 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
* 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: [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
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