Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Ideally, it would be possible to ask for a non-update without a fatal error on old Git versions, but this is not possible (hence, my fix is the portable one, that works on Git 1.8.4). But that's probably the best we can do now. ... and a patch implementing that would look like: This is exactly what I meant by only update when a feature has been flagged. OK, I didn't understand you meant patching Git itself for that. So it makes sense to turn my toy patch into a real patch I guess. Any comment on the capability name? I used dont-update-private, which is a bit long. The actual precise name would be dont-update-private-for-push, but that's really long. Any better idea? Just to be sure: you originally wrote update the remote namespace only when a certain feature has been flagged. My patch differs in two ways: it's opt-out, not opt-in, and it's about updating the _private_ namespace, not the remote. Any comment on what's the best behavior? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: git-remote-mediawiki is kind of a special case, as the remote side uses a very different data model, hence it can make sense to export+reimport to get locally what the remote side received. Hmm, I am not sure how export+reimport would not make sense for others like cvs and p4. Actually, it is essentially what git svn rebase does. I guess it would make even more sense for CVS (I don't know p4, nor git-p4). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Eine große Überraschung für Sie
Heute, Ihre ganz heißen Deal nike Free Schuhe innen online zu speichern. Das Markenzeichen von Nike Free betriebenen Schuhen passiert zu sein unglaublich prominent ausschließlich ein gutes Angebot über mehrere Jahre, All erwägen daher, präsentiert das Nike Free Run 2 Turnschuhe in einem der im Grunde wahrscheinlich der am meisten bevorzugten Turnschuhe ganzen Markt angebaut, und es hat verlängert werden neu in zahlreichen Farben. Nike Womens Run absolut frei Footwear ist nun abailable um Brief Erfolg über hochwertige Materialien und / nike free 4.0 v2 http://www.freerunnikelaufschuhe.eu/nike-free-4-0 oder Farb-Lösungen für einen der Art browse. Nike Lunarlon weiterhin Flywire Technologien Bündel unter Wert auf außergewöhnlichen Komfort zu adaptive, Handschuh-genießen gehen eine kompakte Container. Sie werden bereit sein, wenn Sie wirklich brauchen, um zu verbieten zusätzlich gefährden über die Haltung innerhalb der Spieler arbeitet nike kostenlos Nike unterhält durchsuchen mit einem ausgezeichneten aktuelle System zu Füßen Polsterung. Direkt üblicherweise, dass die Nutzung Entwicklung, unzählige Sterne Elemente nur durch Nike eingeführt. Egal, du bist ein großer Athlet oder anderweitig nicht das größte Schuhe zu haben kann der Nike Marke sein. Für die Jahre dieses Mal hält Nike produziert eine kontinuierlich Schuhe in die Aktivitäten Geschäft. Alle Unternehmen kontinuierlich sorgt dafür, dass jede und jeder von Schuhen vorgesehen Exzellenz weiterhin haltbare Gegenstände gemacht werden, um in der Lage diese Art von Richtung Vergangenheit seit geraumer Zeit sein. Über die Jahrhunderte finden Sie eine Vielzahl von Innovationen finden in Nike Free three.0 Mens diejenigen Herstellung von Nike Schuhe wie das Wesentliche von allen, alle Nike Laufschuhe oder Stiefel. Liebe, weil Nike Free betriebenen Waren betreiben Nike Free 2 und Hilfsmittel Betrieb Realtime Kommentare zu Bereich, Zeitraum, Kalorienverbrauch Daten, Zweck, mit Nike-Chip und dem entsprechenden Gerät bekommen, die insbesondere in Bezug auf die Verbesserung der operativen Effizienz Look. Ones New Tech Nike Free betriebene Schuhe können Ihren Wunsch zu erfüllen. Die meisten Farbabstimmung, bei Läufern bieten mehr Auswahl. Diese Nike Nein an Schuhen Features preislich: kompakte Bauweise zusätzlich entspannt mesh Beschichtung mit sehr guter Brise Durchlässigkeit, Mobilität und Komfort hergestellt. Irgendeine Art von Nike kostenlos betriebene Mens Betriebssystem Turnschuhe haben letter Reise nur das fühlt sich genau wie Sie auf Ihrem nackten Beine, die mit der Sohle ist zu Fuß, zu halten, und auch dämpfend operiert von Standard-Turnschuhe. Sein geringes Gewicht, weil im Inneren auf Zwischensohle sind auch wegen der Außensohle pre-owned. Dieser heißeste Version des Nike Free Eigenschaften lebendige gesunden, eine Website-Setup aus weichem Inhalte, die ähnlich zu den Fingerspitzen bedienen gemacht, um diejenigen aufkommen ebenso vollständig wie möglich. Auch der Einlegesohle ahmt den Kurven der Basis, das Hinzufügen und Bequemlichkeit weiterhin Unterstützung. Dass die Außensohle zeigt Flexkerben ganzen zu helfen, Basisbewegungen erheblich normal, flexible und / oder stabil. Neben nur, dass irgendeine Art von Nike Free Run drei ein Gefühl, das nahtlos in die obere Element der Schuhe war bietet, die bleiben auf diese Wirkung der glatten Overlays. Alle Overlays sorgen kompakt zu halten, wenn es am meisten benötigt wird. Menschen ermutigen, auf Nike Free Run weil alle Schuhe können so bequem während werden es nicht bereuen für diejenigen zu, dass es kaufen zu bewegen. Dies kann ein Top-Schuh, der Sie mit Kilometer zusätzlich Meilen bezüglich Stabilität bieten zusätzlich zu trösten, bevor Sie muss this.The Grund befürworten wir Nike Free Run Sie tauschen entscheiden wäre, dass der Schuh für Menschen gestaltet wird außerdem auf jeden Fall wirklich sein ein luxuriöses einer besonderen, für diejenigen, die einen Versuch haben. Ich bin ja Sie werden definitiv nicht an die Dinge aus der, Für diejenigen, die jede Frage haben, können Sie ganz einfach an Ihren Websites. Rechts Glück! Lesen Sie mehr. http://www.freerunnikelaufschuhe.eu/ - Nike Blazer homme Nike Blazer pas cher -- View this message in context: http://git.661346.n2.nabble.com/Eine-gro-e-Uberraschung-fur-Sie-tp7594605.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] config: add _cb suffix to callback functions
Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build
regression on uClibc which defines fgetc as macro. To work around that
we add a _cb suffix to the callback functions.
Signed-off-by: Natanael Copa nc...@alpinelinux.org
---
config.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/config.c b/config.c
index e13a7b6..aa80078 100644
--- a/config.c
+++ b/config.c
@@ -27,9 +27,9 @@ struct config_source {
struct strbuf value;
struct strbuf var;
- int (*fgetc)(struct config_source *c);
- int (*ungetc)(int c, struct config_source *conf);
- long (*ftell)(struct config_source *c);
+ int (*fgetc_cb)(struct config_source *c);
+ int (*ungetc_cb)(int c, struct config_source *conf);
+ long (*ftell_cb)(struct config_source *c);
};
static struct config_source *cf;
@@ -217,13 +217,13 @@ int git_config_from_parameters(config_fn_t fn, void *data)
static int get_next_char(void)
{
- int c = cf-fgetc(cf);
+ int c = cf-fgetc_cb(cf);
if (c == '\r') {
/* DOS like systems */
- c = cf-fgetc(cf);
+ c = cf-fgetc_cb(cf);
if (c != '\n') {
- cf-ungetc(c, cf);
+ cf-ungetc_cb(c, cf);
c = '\r';
}
}
@@ -992,9 +992,9 @@ int git_config_from_file(config_fn_t fn, const char
*filename, void *data)
top.u.file = f;
top.name = filename;
top.die_on_error = 1;
- top.fgetc = config_file_fgetc;
- top.ungetc = config_file_ungetc;
- top.ftell = config_file_ftell;
+ top.fgetc_cb = config_file_fgetc;
+ top.ungetc_cb = config_file_ungetc;
+ top.ftell_cb = config_file_ftell;
ret = do_config_from(top, fn, data);
@@ -1013,9 +1013,9 @@ int git_config_from_buf(config_fn_t fn, const char *name,
const char *buf,
top.u.buf.pos = 0;
top.name = name;
top.die_on_error = 0;
- top.fgetc = config_buf_fgetc;
- top.ungetc = config_buf_ungetc;
- top.ftell = config_buf_ftell;
+ top.fgetc_cb = config_buf_fgetc;
+ top.ungetc_cb = config_buf_ungetc;
+ top.ftell_cb = config_buf_ftell;
return do_config_from(top, fn, data);
}
@@ -1196,7 +1196,7 @@ static int store_aux(const char *key, const char *value,
void *cb)
return 1;
}
- store.offset[store.seen] = cf-ftell(cf);
+ store.offset[store.seen] = cf-ftell_cb(cf);
store.seen++;
}
break;
@@ -1223,19 +1223,19 @@ static int store_aux(const char *key, const char
*value, void *cb)
* Do not increment matches: this is no match, but we
* just made sure we are in the desired section.
*/
- store.offset[store.seen] = cf-ftell(cf);
+ store.offset[store.seen] = cf-ftell_cb(cf);
/* fallthru */
case SECTION_END_SEEN:
case START:
if (matches(key, value)) {
- store.offset[store.seen] = cf-ftell(cf);
+ store.offset[store.seen] = cf-ftell_cb(cf);
store.state = KEY_SEEN;
store.seen++;
} else {
if (strrchr(key, '.') - key == store.baselen
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
- store.offset[store.seen] =
cf-ftell(cf);
+ store.offset[store.seen] =
cf-ftell_cb(cf);
}
}
}
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add gui.displayuntracked option
Max Kirillov m...@max630.net writes:
When git is used to track only a subset of a directory, or
there is no sure way to divide files to ignore from files to track,
git user have to live with large number of untracked files. These files
present in file list, and should always be scrolled through
to handle real changes. Situation can become even worse, then number
of the untracked files grows above the maxfilesdisplayed limit. In the
case, even staged can be hidden by git-gui.
This change introduces new configuration variable gui.displayuntracked,
which, when set to false, instructs git-gui not to show untracked files
in files list. They can be staged from commandline or other tools (like
IDE of file manager), then they become visible. Default value of the
option is true, which is compatible with current behavior.
Signed-off-by: Max Kirillov m...@max630.net
---
Hi. I've been using git for some time and have collected a
number of changes which might worth sharing.
Please consider adding them to the upstream.
Thanks,
Max
Documentation/config.txt | 4
git-gui/git-gui.sh | 14 ++
git-gui/lib/option.tcl | 1 +
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bbba728..7a786b2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1277,6 +1277,10 @@ gui.diffcontext::
Specifies how many context lines should be used in calls to diff
made by the linkgit:git-gui[1]. The default is 5.
+gui.displayuntracked::
+ Determines if linkgit::git-gui[1] shows untracked files
+ in the file list. The defaulit is true.
+
gui.encoding::
Specifies the default encoding to use for displaying of
file contents in linkgit:git-gui[1] and linkgit:gitk[1].
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 89f636f..42c35ad 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -898,6 +898,7 @@ set font_descs {
{fontdiff font_diff {mc Diff/Console Font}}
}
set default_config(gui.stageuntracked) ask
+set default_config(gui.displayuntracked) true
##
##
@@ -1536,18 +1537,23 @@ proc rescan_stage2 {fd after} {
set buf_rdf {}
set buf_rlo {}
- set rescan_active 3
+ set rescan_active 2
ui_status [mc Scanning for modified files ...]
set fd_di [git_read diff-index --cached -z [PARENT]]
set fd_df [git_read diff-files -z]
- set fd_lo [eval git_read ls-files --others -z $ls_others]
fconfigure $fd_di -blocking 0 -translation binary -encoding binary
fconfigure $fd_df -blocking 0 -translation binary -encoding binary
- fconfigure $fd_lo -blocking 0 -translation binary -encoding binary
+
fileevent $fd_di readable [list read_diff_index $fd_di $after]
fileevent $fd_df readable [list read_diff_files $fd_df $after]
- fileevent $fd_lo readable [list read_ls_others $fd_lo $after]
+
+ if {[is_config_true gui.displayuntracked]} {
+ set fd_lo [eval git_read ls-files --others -z $ls_others]
+ fconfigure $fd_lo -blocking 0 -translation binary -encoding
binary
+ fileevent $fd_lo readable [list read_ls_others $fd_lo $after]
+ incr rescan_active
+ }
}
proc load_message {file {encoding {}}} {
diff --git a/git-gui/lib/option.tcl b/git-gui/lib/option.tcl
index 0cf1da1..2177db6 100644
--- a/git-gui/lib/option.tcl
+++ b/git-gui/lib/option.tcl
@@ -159,6 +159,7 @@ proc do_options {} {
{c gui.encoding {mc Default File Contents Encoding}}
{b gui.warndetachedcommit {mc Warn before committing to a
detached head}}
{s gui.stageuntracked {mc Staging of untracked files} {list
yes no ask}}
+ {b gui.displayuntracked {mc Show untracked files}}
} {
set type [lindex $option 0]
set name [lindex $option 1]
Looks fine to me. The Documentation part of the patch will need to be
sent separately to the git project later when this is merged in as
git-gui is managed in a separate repository. It also has a typo in
'default'. I'll make a note to forward this part of the patch at
request-pull time.
--
Pat Thoytshttp://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-gui: right half window is paned
Max Kirillov m...@max630.net writes:
For long descriptions it would be nice to be able to resize
the comment text field.
Signed-off-by: Max Kirillov m...@max630.net
---
git-gui/git-gui.sh | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 89f636f..e2e710e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3196,13 +3196,19 @@ unset i
# -- Diff and Commit Area
#
-${NS}::frame .vpane.lower -height 300 -width 400
+${NS}::panedwindow .vpane.lower -orient vertical
${NS}::frame .vpane.lower.commarea
-${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1
-pack .vpane.lower.diff -fill both -expand 1
-pack .vpane.lower.commarea -side bottom -fill x
+${NS}::frame .vpane.lower.diff -relief sunken -borderwidth 1 -height 500
+.vpane.lower add .vpane.lower.diff
+.vpane.lower add .vpane.lower.commarea
.vpane add .vpane.lower
-if {!$use_ttk} {.vpane paneconfigure .vpane.lower -sticky nsew}
+if {$use_ttk} {
+ .vpane.lower pane .vpane.lower.diff -weight 1
+ .vpane.lower pane .vpane.lower.commarea -weight 0
+} else {
+ .vpane.lower paneconfigure .vpane.lower.diff -stretch always
+ .vpane.lower paneconfigure .vpane.lower.commarea -stretch never
+}
# -- Commit Area Buttons
#
Also fine and applied. Thank you.
--
Pat Thoytshttp://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Donation Funds
My wife and i won £148.6 Million Pounds last year, and we have done lot of charity donation, so we decide to give 1.5Million Pounds each to 5 lucky people this June 2013, lucky for you, your email, was given to us by google managment as one of our lucky receipants. For verification process see below Please read the article - http://www.bbc.co.uk/news/uk-england-19254228 Send Name, Country, Age, Occupation and Phone Number for details Congratulations Happy Celebrations in Advance, Gillian and Adrian Bayford Email: gillian.adrianbayfor...@rogers.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Document pack v4 format
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
For my education but may help people who are interested in the
format. Most is gathered from commit messages, except the delta tree
entries.
.idx is not documented yet, but it does not change much and not the
focus right now anyway.
Documentation/technical/pack-format-v4.txt (new) | 110 +++
1 file changed, 110 insertions(+)
create mode 100644 Documentation/technical/pack-format-v4.txt
diff --git a/Documentation/technical/pack-format-v4.txt
b/Documentation/technical/pack-format-v4.txt
new file mode 100644
index 000..9123a53
--- /dev/null
+++ b/Documentation/technical/pack-format-v4.txt
@@ -0,0 +1,110 @@
+Git pack v4 format
+==
+
+== pack-*.pack files have the following format:
+
+ - A header appears at the beginning and consists of the following:
+
+ 4-byte signature:
+ The signature is: {'P', 'A', 'C', 'K'}
+
+ 4-byte version number (network byte order): must be version
+ number 4
+
+ 4-byte number of objects contained in the pack (network byte
+ order)
+
+ - (20 * nr_objects)-byte SHA-1 table: sorted in memcmp() order.
+
+ - Commit name dictionary: the uncompressed length in variable
+ encoding, followed by zlib-compressed dictionary. Each entry
+ consists of two prefix bytes storing timezone followed by a
+ NUL-terminated string.
+
+ Entries should be sorted by frequency so that the most frequent
+ entry has the smallest index, thus most efficient variable
+ encoding.
+
+ - Tree path dictionary: similar format to commit name
+ dictionary. Each entry consists of two prefix bytes storing entry
+ mode, then a NUL-terminated path name. Same sort order
+ recommendation applies.
+
+ - The header is followed by number of object entries, each of
+ which looks like this:
+
+ (undeltified representation)
+ n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+ [uncompressed data]
+ [compressed data]
+
+ (deltified representation)
+ n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+ base object name in SHA-1 reference encoding
+ compressed delta data
+
+ In undeltified format, blobs and tags do not have the
+ uncompressed data, all object content is compressed. Trees are
+ not compressed at all. Some headers in commits are stored
+ uncompressed, the rest is compressed.
+
+ All objects except trees are deltified and compressed the same
+ way in v3. Trees however are deltified differently and use
+ undeltified representation. See Tree representation below for
+ details.
+
+ - The trailer records 20-byte SHA-1 checksum of all of the above.
+
+=== Commit representation
+
+ - n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+
+ - Tree SHA-1 in SHA-1 reference encoding
+
+ - Parent count in variable length encoding
+
+ - Parent SHA-1s in SHA-1 reference encoding
+
+ - Author reference: the index, in variable length encoding, to comit
+name dictionary, which covers the name and also the time zone.
+
+ - Author timestamp in variable length encoding
+
+ - Committer reference: the index, in variable length encoding, to
+comit name dictionary, which covers the name and also the time
+zone.
+
+ - Committer timestamp in variable length encoding
+
+ - Compressed data of remaining header and the body
+
+=== Tree representation
+
+ - n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+
+ - Number of trees in variable length encoding
+
+ - A number of trees, each consists of
+
+Path component reference: an index, in variable length encoding,
+into tree path dictionary, which also covers entry mode.
+
+SHA-1 in SHA-1 reference encoding.
+
+Path component reference zero is an indicator of deltified portion and
+has the following format:
+
+ - path component reference: zero
+
+ - index of the entry to copy from, in variable length encoding
+
+ - number of entries in variable length encoding
+
+ - base tree in SHA-1 reference encoding
+
+=== SHA-1 reference encoding
+
+This encoding is used to encode SHA-1 efficiently if it's already in
+the SHA-1 table. It starts with an index number in variable length
+encoding. If it's not zero, its value minus one is the index in the
+SHA-1 table. If it's zero, 20 bytes of SHA-1 is followed.
--
1.8.2.83.gc99314b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Fix path prefixing in grep_object
On Tue, Aug 27, 2013 at 12:07 AM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Not necessarily. If the user is asking the question in a more natural way (I want to see where in 'next' branch's tip commit hits appear, by the way, I know I am only interested in builtin/ so I'd give pathspec as well when I am asking this question), the output does give commit colon path, so it is more than coincidence. This part needs to be qualified. Natural is of course in the eyes of beholder. If we assume that your #1 holds true (i.e. the tuple in which tree object are we reporting, what path we saw hits is important and merging them into one in what blob we saw hits lose information), My #1 is really what I inferred from your statements. I did not think the tuple was important, but I agree that may be my shortsightedness. If the tuple is important, then it seems to me that the --null behavior is a bug (the colon is left intact); but changing it now seems senseless or harmful. then it is natural to ask inside origin/master tree, where do I have hits? By the way, I am only interested in builtin/ and get origin/master:builtin/pack-objects.c as an answer (this is from your earlier example), than asking inside origin/master:builtin tree, where do I have hits? If we do not consider #1 is false and the tree information can be discarded, then it does not matter if we converted the colon after origin/master to slash when we answer the latter question, and the latter question stops being unnatural. ... but it might be a good change to allow A:B:C to be parsed as a proper extended SHA-1 expression and make it yield git rev-parse $(git rev-parse $(git rev-parse A):B):C Right now, B:C is used as a path inside tree-ish A, but I think we can safely fall back, when path B:C does not appear in tree-ish A, to see if path B appears in it and is a tree, and then turn it into a look-up of path C in that tree A:B. And if we want to keep the tree, path tuple, but still want to make it easier to work with the output, allowing A:B:C to be parsed as an extended SHA-1 expression would be a reasonable solution, not a work-around. The answer is given to the question asked in either way (either in origin/master, but limited to these pathspecs or in the tree origin/master:builtin/) without losing information, but the issue you had is that the answer to the latter form of question is not understood by the object name parser, which I personally think is a bug. I am beginning to agree, though we discovered some other weird output from grep which also does not parse. (origin/master:../relative/path). It seems that fixing this bug could be very confusing for get_sha1_with_context unless the context was rewritten to match the traditional syntax. P -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote: filter out invalid remote configurations
In remote's configuration callback, anything that looks like
'remote.name.*' creates a remote 'name'. This remote may not end
up having any configuration for a remote, but it's still in the list,
so 'git remote' shows it, which means something like
[remote bogus]
hocus = pocus
will show a remote 'bogus' in the listing, even though it won't work
as a remote name for either git-fetch or git-push.
Filter out the remotes that we created which have no urls in order to
work around such configuration entries.
Signed-off-by: Carlos Martín Nieto c...@elego.de
---
Due to git's callback-based config, it seemed a lot simpler to let it
do it wrong and then filter out what won't be usable, rather than
delaying the creation of a remote until we're sure we do want it.
The tests that made use of a remote 'existing' with just .fetch seem
to be written that way because they can get away with it, rather than
any assertion that it should be allowed in day-to-day git usage, but
correct me if I'm wrong.
remote.c | 17 +
t/t5505-remote.sh | 2 ++
t/t7201-co.sh | 2 +-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index 68eb99b..00a1d7a 100644
--- a/remote.c
+++ b/remote.c
@@ -141,6 +141,9 @@ static struct remote *make_remote(const char *name, int len)
int i;
for (i = 0; i remotes_nr; i++) {
+ if (!remotes[i])
+ continue;
+
if (len ? (!strncmp(name, remotes[i]-name, len)
!remotes[i]-name[len]) :
!strcmp(name, remotes[i]-name))
@@ -469,6 +472,19 @@ static int handle_config(const char *key, const char
*value, void *cb)
return 0;
}
+static void filter_valid_remotes(void)
+{
+ int i;
+ for (i = 0; i remotes_nr; i++) {
+ if (!remotes[i])
+ continue;
+
+ /* It's not a remote unless it has at least one url */
+ if (remotes[i]-url_nr == 0 remotes[i]-pushurl_nr == 0)
+ remotes[i] = NULL;
+ }
+}
+
static void alias_all_urls(void)
{
int i, j;
@@ -504,6 +520,7 @@ static void read_config(void)
make_branch(head_ref + strlen(refs/heads/), 0);
}
git_config(handle_config, NULL);
+ filter_valid_remotes();
alias_all_urls();
}
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index dd10ff0..848e7b7 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -130,9 +130,11 @@ to delete them, use:
EOF
}
git tag footag
+ git remote add oops .
git config --add remote.oops.fetch +refs/*:refs/*
git remote remove oops 2actual1
git branch foobranch
+ git remote add oops .
git config --add remote.oops.fetch +refs/*:refs/*
git remote rm oops 2actual2
git branch -d foobranch
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 0c9ec0a..4647f1c 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -431,7 +431,7 @@ test_expect_success 'detach a symbolic link HEAD' '
test_expect_success \
'checkout with --track fakes a sensible -b name' '
-git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
+git remote add origin .
git update-ref refs/remotes/origin/koala/bear renamer
git checkout --track origin/koala/bear
--
1.8.4.561.g1c3d45d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] core.precomposeunicode is true by default
(Sorry for the somewhat late reply, thanks for review)
Torsten Bögershausen tbo...@web.de writes:
When core.precomposeunicode was introduced, it was set to false
by default, to be compatible with older versions of Git.
Whenever UTF-8 file names are used in a mixed environment,
the Mac OS users need to find out that this configuration exist
and set it to true manually.
There is no measurable performance impact between false and true.
The real reason we default it to auto-sensing in the current code is
for correctness, I think. the new precompose code could be buggy,
and by auto-sensing, we hoped that we would enable it only on
filesystems that the codepath matters.
A smoother workflow can be achieved for new Git users,
so change the default to true:
- Remove the auto-sensing
Why?
- Rename the internal variable into precompose_unicode,
and set it to 1 meaning true.
Why the rename?
- Adjust and clean up test cases
The configuration core.precomposeunicode is still supported.
Sorry, but I do not quite understand the change. Is this because
the auto-sensing is not working, or after auto-sensing we do a wrong
thing? If that is the case, perhaps that is what we should fix?
diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index 7980abd..5396b91 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -36,30 +36,6 @@ static size_t has_non_ascii(const char *s, size_t maxlen,
size_t *strlen_c)
}
-void probe_utf8_pathname_composition(char *path, int len)
-{
-static const char *auml_nfc = \xc3\xa4;
-static const char *auml_nfd = \x61\xcc\x88;
-int output_fd;
-if (precomposed_unicode != -1)
-return; /* We found it defined in the global config, respect it
*/
-strcpy(path + len, auml_nfc);
-output_fd = open(path, O_CREAT|O_EXCL|O_RDWR, 0600);
So we try to create a path under one name, and ...
-if (output_fd = 0) {
-close(output_fd);
-strcpy(path + len, auml_nfd);
-/* Indicate to the user, that we can configure it to true */
-if (!access(path, R_OK))
-git_config_set(core.precomposeunicode, false);
... see if that path can be seen under its alias. Why do we set it
to false? Isn't this the true culprit?
After all, this is not in the reinit codepath, so we know we are
dealing with a repository that was created afresh.
There is nothing wrong with the auto-sensing as such.
The problem for many users today is that we set core.precomposeunicode
to false, when it should be true.
A patch for that comes out in a minute. But first look back and
collect some experience with core.precomposeunicode.
Lets have a look at the variable precomposed_unicode,
(the one I wanted to rename to be more consistant).
It is controlled by the git config files and
depending on the config it is set like this:
core.precomposeuinicode false - precomposed_unicode = 0
core.precomposeuinicode true - precomposed_unicode = 1
core.precomposeuinicode not set - precomposed_unicode = -1.
Let's look what precomposed_unicode does and go through a couple
of git operations.
1)
When we create a repo under Mac OS using HFS+,
we want to have precomposed_unicode = 1
2)
When we access a repo from Windows/Linux using SAMBA,
readdir() will return decomposed.
When the repo is created by nonMacOS, core.precomposeunicode is undefined.
The precomposition is off, but should be on,
precomposed_unicode = -1, but should be = 1
3)
When we access a repo from another Mac OS system using
SAMBA, NFS or AFP readdir() will return decomposed.
As the repo is created under Mac OS, we have the same case as (1)
4)
When we access a repo from Linux using NFS we can have
precomposed_unicode = 0 (which is technically more correct).
If Linux users do not use decomposed unicode in their file names,
(according to my understanding this is the case), we can use 1
as well as 0:
precomposing an already precomposed string is a no-op, so it doesn't
harm.
5)
When we create a repo under Linux/Windows on a USB-drive,
and run git status under Mac OS, we want precomposed_unicode = 1.
There are few cases where we want to use precomposed_unicode=0:
a) To work around bugs. This may be a short term solution,
I would rather see bugs to be fixed.
I'm not aware of any bugs, so please remind me if I missed something.
b) Working with foreign vcs: E.g. bzr and hg use decomposed unicode,
so it may be better to use decomposed unicode in git as well.
The simplified V2 patch looks like this (I send it in a seperate mail):
diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index 7980abd..95fe849 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -48,11 +48,8 @@ void probe_utf8_pathname_composition(char *path, int len)
if (output_fd = 0) {
close(output_fd);
strcpy(path + len, auml_nfd);
- /* Indicate to the
BUG: git subtree split - revert commit followed by a merge
Hello: I'm running into the problem described in this mailing list post: http://thread.gmane.org/gmane.comp.version-control.git/202645 'git subtree split' fails to reconstruct the history when a revert commit is followed by a merge commit. I have slightly adjusted the test script provided by Fabien in his mailing list post: git init # create a directory that is going to be split mkdir doc echo TEST doc/README git add doc # commit A git commit -a -mfirst version # create a branch with a new commit (Z) git checkout -b test echo TEST doc/README1 git add doc/README1 git commit -a -madded README1 git checkout master # modify the README file (commit B) echo TEST_ doc/README git commit -a -msecond version # revert the change (commit C) echo TEST doc/README git commit -a -mrevert second version # or use git revert HEAD^ # split git subtree split --prefix=doc --branch=TARGET # add another commit (to a file *not* in the subtree dir) echo BLA BLA git add BLA git commit -a -mthird version # adding another commit to a file in the subtree dir will fix things #echo MEH doc/MEH #git add doc #git commit -a -mfourth version # the log will show the 3 commits as expected (including B and C) GIT_PAGER= git log --oneline TARGET # merge the test branch git merge -mmerged test test # attempt to re-split; this will fail git subtree split --prefix=doc --branch=TARGET # see what history split generates git subtree split --prefix=doc --branch=TARGET2 I have discovered that if the revert commit is followed by another commit that makes changes in the subtree directory, the split will work as expected (see fourth version above). See also this related SO question where I ask for a workaround: http://stackoverflow.com/questions/18465867 Best regards, Brecht -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v2] Set core.precomposeunicode to true on e.g. HFS+
When core.precomposeunicode was introduced in 76759c7d,
it was set to false on a unicode decomposing file system like HFS+
to be compatible with older versions of Git.
The Mac OS users need to find out that this configuration exist
and change it manually from false to true.
A smoother workflow can be achieved,
so set core.precomposeunicode to true on a decomposing file system.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
compat/precompose_utf8.c | 7 ++-
t/t0050-filesystem.sh| 1 +
t/t3910-mac-os-precompose.sh | 2 +-
t/t7400-submodule-basic.sh | 1 -
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index 7980abd..95fe849 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -48,11 +48,8 @@ void probe_utf8_pathname_composition(char *path, int len)
if (output_fd = 0) {
close(output_fd);
strcpy(path + len, auml_nfd);
- /* Indicate to the user, that we can configure it to true */
- if (!access(path, R_OK))
- git_config_set(core.precomposeunicode, false);
- /* To be backward compatible, set precomposed_unicode to 0 */
- precomposed_unicode = 0;
+ precomposed_unicode = access(path, R_OK) ? 0 : 1;
+ git_config_set(core.precomposeunicode, precomposed_unicode ?
true : false);
strcpy(path + len, auml_nfc);
if (unlink(path))
die_errno(_(failed to unlink '%s'), path);
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 05d78d2..6b3cedc 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -91,6 +91,7 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different
case)' '
test_expect_success setup unicode normalization tests '
test_create_repo unicode
cd unicode
+ git config core.precomposeunicode false
touch $aumlcdiar
git add $aumlcdiar
git commit -m initial
diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
index 5fe57c5..e4ba601 100755
--- a/t/t3910-mac-os-precompose.sh
+++ b/t/t3910-mac-os-precompose.sh
@@ -36,7 +36,7 @@ Alongc=$Alongc$AEligatu$AEligatu #254 Byte
test_expect_success detect if nfd needed '
precomposeunicode=`git config core.precomposeunicode`
- test $precomposeunicode = false
+ test $precomposeunicode = true
git config core.precomposeunicode true
'
test_expect_success setup '
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5ee97b0..f0f8cde 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -958,7 +958,6 @@ test_expect_success 'submodule with UTF-8 name' '
git add sub
git commit -m init sub
)
- test_config core.precomposeunicode true
git submodule add ./$svname
git submodule 2
test -n $(git submodule | grep $svname)
--
1.8.4.rc0.177.gceb3200
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] documentation: clarify notes for clean.requireForce
Add -i (interactive clean option) to clarify the documentation for clean.requireForce config variable. Also replace the example in `gitcli.txt` with safer git clean command. Signed-off-by: Jiang Xin worldhello@gmail.com --- Documentation/config.txt | 4 ++-- Documentation/gitcli.txt | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8361380..547149d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -795,8 +795,8 @@ browser.tool.path:: working repository in gitweb (see linkgit:git-instaweb[1]). clean.requireForce:: - A boolean to make git-clean do nothing unless given -f - or -n. Defaults to true. + A boolean to make git-clean do nothing unless given -i, + -f or -n. Defaults to true. color.branch:: A boolean to enable/disable color in the output of diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 9ac5088..4005a3b 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -135,7 +135,7 @@ Aggregating short options ~ Commands that support the enhanced option parser allow you to aggregate short options. This means that you can for example use `git rm -rf` or -`git clean -fdx`. +`git clean -idx`. Abbreviating long options -- 1.8.4.rc3.2.gf223459 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Asymmetric default behavior of git stash
Hi, is there any reason why the default behavior of git stash is asymmetric? When I save my current state with 'git stash save' it saves the worktree changes and the index changes (and resets both). When I restore the state with 'git stash pop' it restores the worktree changes, but not the state of the index. Your work preparing the index is lost. Although this behavior is documented it is kind of unexpected. From a save-restore mechanism I would expect that the default behavior would restore the state as it was before the save. So I would expect it to either save and restore the worktree and leave the index alone or save and restore both, the worktree and the index. Regards Uwe -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Set core.precomposeunicode to true on e.g. HFS+
Torsten Bögershausen tbo...@web.de writes: When core.precomposeunicode was introduced in 76759c7d, it was set to false on a unicode decomposing file system like HFS+ to be compatible with older versions of Git. The Mac OS users need to find out that this configuration exist and change it manually from false to true. Yeah, I think this makes sense. I actually wonder why we thought that the way 76759c7d (git on Mac OS and precomposed unicode, 2012-07-08) did add the variable to the config but do not enable was a good idea. If I recall correctly, the justification was that way the users will not be suddenly affected by the behaviour change, but can notice an unfamiliar variable in their configuration and flip it as needed; I said that it did not make sense to me ($gmane/188940) back then and now I think with this patch we are in agreement ;-). - /* Indicate to the user, that we can configure it to true */ - if (!access(path, R_OK)) - git_config_set(core.precomposeunicode, false); - /* To be backward compatible, set precomposed_unicode to 0 */ - precomposed_unicode = 0; + precomposed_unicode = access(path, R_OK) ? 0 : 1; + git_config_set(core.precomposeunicode, precomposed_unicode ? true : false); This test is very conservative in that only a successful access() will flip the bit; I like it. Will queue. Thanks. strcpy(path + len, auml_nfc); if (unlink(path)) die_errno(_(failed to unlink '%s'), path); diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index 05d78d2..6b3cedc 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -91,6 +91,7 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' test_expect_success setup unicode normalization tests ' test_create_repo unicode cd unicode + git config core.precomposeunicode false touch $aumlcdiar git add $aumlcdiar git commit -m initial diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh index 5fe57c5..e4ba601 100755 --- a/t/t3910-mac-os-precompose.sh +++ b/t/t3910-mac-os-precompose.sh @@ -36,7 +36,7 @@ Alongc=$Alongc$AEligatu$AEligatu #254 Byte test_expect_success detect if nfd needed ' precomposeunicode=`git config core.precomposeunicode` - test $precomposeunicode = false + test $precomposeunicode = true git config core.precomposeunicode true ' test_expect_success setup ' diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh index 5ee97b0..f0f8cde 100755 --- a/t/t7400-submodule-basic.sh +++ b/t/t7400-submodule-basic.sh @@ -958,7 +958,6 @@ test_expect_success 'submodule with UTF-8 name' ' git add sub git commit -m init sub ) - test_config core.precomposeunicode true git submodule add ./$svname git submodule 2 test -n $(git submodule | grep $svname) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH/RFC man git remote, use of remote vs name
I noticed that http://jk.gs/git-remote.html mostly refers to remotes as name, but in one case as remote. remote is clearer than name, and also follows the pattern of url, branch and so on. Here follows a patch in which the usage is made consistent, as remote rather than name. I hope the format is OK. Thanks, Daniele From 3b9d6847286b70b9ee1711af5b9cf3dd7a91c2cc Mon Sep 17 00:00:00 2001 From: Daniele Procida dani...@vurt.org Date: Tue, 27 Aug 2013 13:08:37 +0100 Subject: [PATCH] made git man remote more consistent --- Documentation/git-remote.txt | 56 ++-- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 9c3e3bf..12cdf04 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -10,16 +10,16 @@ SYNOPSIS [verse] 'git remote' [-v | --verbose] -'git remote add' [-t branch] [-m master] [-f] [--[no-]tags] [--mirror=fetch|push] name url +'git remote add' [-t branch] [-m master] [-f] [--[no-]tags] [--mirror=fetch|push] remote url 'git remote rename' old new -'git remote remove' name -'git remote set-head' name (-a | -d | branch) -'git remote set-branches' [--add] name branch... -'git remote set-url' [--push] name newurl [oldurl] -'git remote set-url --add' [--push] name newurl -'git remote set-url --delete' [--push] name url -'git remote' [-v | --verbose] 'show' [-n] name... -'git remote prune' [-n | --dry-run] name... +'git remote remove' remote +'git remote set-head' remote (-a | -d | branch) +'git remote set-branches' [--add] remote branch... +'git remote set-url' [--push] remote newurl [oldurl] +'git remote set-url --add' [--push] remote newurl +'git remote set-url --delete' [--push] remote url +'git remote' [-v | --verbose] 'show' [-n] remote... +'git remote prune' [-n | --dry-run] remote... 'git remote' [-v | --verbose] 'update' [-p | --prune] [(group | remote)...] DESCRIPTION @@ -45,26 +45,26 @@ subcommands are available to perform operations on the remotes. 'add':: -Adds a remote named name for the repository at -url. The command `git fetch name` can then be used to create and -update remote-tracking branches name/branch. +Adds a remote named remote for the repository at +url. The command `git fetch remote` can then be used to create and +update remote-tracking branches remote/branch. + -With `-f` option, `git fetch name` is run immediately after +With `-f` option, `git fetch remote` is run immediately after the remote information is set up. + -With `--tags` option, `git fetch name` imports every tag from the +With `--tags` option, `git fetch remote` imports every tag from the remote repository. + -With `--no-tags` option, `git fetch name` does not import tags from +With `--no-tags` option, `git fetch remote` does not import tags from the remote repository. + With `-t branch` option, instead of the default glob refspec for the remote to track all branches under -the `refs/remotes/name/` namespace, a refspec to track only `branch` +the `refs/remotes/remote/` namespace, a refspec to track only `branch` is created. You can give more than one `-t branch` to track multiple branches without grabbing all branches. + -With `-m master` option, a symbolic-ref `refs/remotes/name/HEAD` is set +With `-m master` option, a symbolic-ref `refs/remotes/remote/HEAD` is set up to point at remote's `master` branch. See also the set-head command. + When a fetch mirror is created with `--mirror=fetch`, the refs will not @@ -88,29 +88,29 @@ the configuration file format. 'remove':: 'rm':: -Remove the remote named name. All remote-tracking branches and +Remove the remote named remote. All remote-tracking branches and configuration settings for the remote are removed. 'set-head':: Sets or deletes the default branch (i.e. the target of the -symbolic-ref `refs/remotes/name/HEAD`) for +symbolic-ref `refs/remotes/remote/HEAD`) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for `origin` is set to `master`, then `origin` may be specified wherever you would normally specify `origin/master`. + -With `-d`, the symbolic ref `refs/remotes/name/HEAD` is deleted. +With `-d`, the symbolic ref `refs/remotes/remote/HEAD` is deleted. + With `-a`, the remote is queried to determine its `HEAD`, then the -symbolic-ref `refs/remotes/name/HEAD` is set to the same branch. e.g., if the remote +symbolic-ref `refs/remotes/remote/HEAD` is set to the same branch. e.g., if the remote `HEAD` is pointed at `next`, `git remote set-head origin -a` will set the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will only work if `refs/remotes/origin/next` already exists; if not it must be fetched first. + -Use `branch` to set the symbolic-ref `refs/remotes/name/HEAD`
Re: [PATCH/RFC] core.precomposeunicode is true by default
Torsten Bögershausen tbo...@web.de writes: ... see if that path can be seen under its alias. Why do we set it to false? Isn't this the true culprit? After all, this is not in the reinit codepath, so we know we are dealing with a repository that was created afresh. There is nothing wrong with the auto-sensing as such. The problem for many users today is that we set core.precomposeunicode to false, when it should be true. I think we are in agreement then. The code detects a broken filesystem just fine, but what it does when it finds the filesystem is broken is wrong---it sets the variable to false. That makes the whole auto-sensing wrong, and I think it makes sense to correct that behaviour. Let's look what precomposed_unicode does and go through a couple of git operations. 1) When we create a repo under Mac OS using HFS+, we want to have precomposed_unicode = 1 Yes. 2) When we access a repo from Windows/Linux using SAMBA, You mean s/repo/repository that resides on HFS+/? readdir() will return decomposed. When the repo is created by nonMacOS, core.precomposeunicode is undefined. The precomposition is off, but should be on, precomposed_unicode = -1, but should be = 1 I do not think UTF-8-MAC is widely available; even if you flip the bit on, would it help much? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote: filter out invalid remote configurations
Carlos Martín Nieto c...@elego.de writes: In remote's configuration callback, anything that looks like 'remote.name.*' creates a remote 'name'. This remote may not end up having any configuration for a remote, but it's still in the list, so 'git remote' shows it, which means something like [remote bogus] hocus = pocus will show a remote 'bogus' in the listing, even though it won't work as a remote name for either git-fetch or git-push. Isn't this something the user may want to be aware of, though? Hiding these would rob a chance for such an entry to be noticed from the user---is it a good change? Filter out the remotes that we created which have no urls in order to work around such configuration entries. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: add _cb suffix to callback functions
Natanael Copa nc...@alpinelinux.org writes:
Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build
regression on uClibc which defines fgetc as macro. To work around that
we add a _cb suffix to the callback functions.
Signed-off-by: Natanael Copa nc...@alpinelinux.org
---
Thanks; I think Peff already fixed this yesterday.
Just for future reference, a looong commit object name like this
Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build
is not very friendly to human readers in a log message; it does not
help tickle their memory.
4d8dd149 (config: make parsing stack struct independent from
actual data source, 2013-07-12) introduced...
may be a way to phrase it in a more useful way.
config.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/config.c b/config.c
index e13a7b6..aa80078 100644
--- a/config.c
+++ b/config.c
@@ -27,9 +27,9 @@ struct config_source {
struct strbuf value;
struct strbuf var;
- int (*fgetc)(struct config_source *c);
- int (*ungetc)(int c, struct config_source *conf);
- long (*ftell)(struct config_source *c);
+ int (*fgetc_cb)(struct config_source *c);
+ int (*ungetc_cb)(int c, struct config_source *conf);
+ long (*ftell_cb)(struct config_source *c);
};
static struct config_source *cf;
@@ -217,13 +217,13 @@ int git_config_from_parameters(config_fn_t fn, void
*data)
static int get_next_char(void)
{
- int c = cf-fgetc(cf);
+ int c = cf-fgetc_cb(cf);
if (c == '\r') {
/* DOS like systems */
- c = cf-fgetc(cf);
+ c = cf-fgetc_cb(cf);
if (c != '\n') {
- cf-ungetc(c, cf);
+ cf-ungetc_cb(c, cf);
c = '\r';
}
}
@@ -992,9 +992,9 @@ int git_config_from_file(config_fn_t fn, const char
*filename, void *data)
top.u.file = f;
top.name = filename;
top.die_on_error = 1;
- top.fgetc = config_file_fgetc;
- top.ungetc = config_file_ungetc;
- top.ftell = config_file_ftell;
+ top.fgetc_cb = config_file_fgetc;
+ top.ungetc_cb = config_file_ungetc;
+ top.ftell_cb = config_file_ftell;
ret = do_config_from(top, fn, data);
@@ -1013,9 +1013,9 @@ int git_config_from_buf(config_fn_t fn, const char
*name, const char *buf,
top.u.buf.pos = 0;
top.name = name;
top.die_on_error = 0;
- top.fgetc = config_buf_fgetc;
- top.ungetc = config_buf_ungetc;
- top.ftell = config_buf_ftell;
+ top.fgetc_cb = config_buf_fgetc;
+ top.ungetc_cb = config_buf_ungetc;
+ top.ftell_cb = config_buf_ftell;
return do_config_from(top, fn, data);
}
@@ -1196,7 +1196,7 @@ static int store_aux(const char *key, const char
*value, void *cb)
return 1;
}
- store.offset[store.seen] = cf-ftell(cf);
+ store.offset[store.seen] = cf-ftell_cb(cf);
store.seen++;
}
break;
@@ -1223,19 +1223,19 @@ static int store_aux(const char *key, const char
*value, void *cb)
* Do not increment matches: this is no match, but we
* just made sure we are in the desired section.
*/
- store.offset[store.seen] = cf-ftell(cf);
+ store.offset[store.seen] = cf-ftell_cb(cf);
/* fallthru */
case SECTION_END_SEEN:
case START:
if (matches(key, value)) {
- store.offset[store.seen] = cf-ftell(cf);
+ store.offset[store.seen] = cf-ftell_cb(cf);
store.state = KEY_SEEN;
store.seen++;
} else {
if (strrchr(key, '.') - key == store.baselen
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
- store.offset[store.seen] =
cf-ftell(cf);
+ store.offset[store.seen] =
cf-ftell_cb(cf);
}
}
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] Preliminary pack v4 support
Nicolas Pitre n...@fluxnic.net writes: Subject says it all... at last ! This can also be fetched here: git://git.linaro.org/people/nico/git Demonstration of what it does at the moment: http://article.gmane.org/gmane.comp.version-control.git/233038 I'd like to preserve the author time stamps as they relate to where in the world I was when the corresponding code was written. You'll notice I didn't work on the code in the same order as it is now presented. We can also notice things like From: user@machine.(none) ;-) Still open question: what to do with a thin pack. Should we really complete it with local objects upon reception, or were we only over paranoid at the time we imposed this rule? I do not think paranoia had much to do with it. I am afraid that allowing a delta in a pack to depend on a base in another pack means that the former pack becomes unusable without the latter, which would make object store management (e.g. partial repacking) a lot more cumbersome, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] core.precomposeunicode is true by default
On 27.08.13 16:49, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: ... see if that path can be seen under its alias. Why do we set it to false? Isn't this the true culprit? After all, this is not in the reinit codepath, so we know we are dealing with a repository that was created afresh. There is nothing wrong with the auto-sensing as such. The problem for many users today is that we set core.precomposeunicode to false, when it should be true. I think we are in agreement then. The code detects a broken filesystem just fine, but what it does when it finds the filesystem is broken is wrong---it sets the variable to false. That makes the whole auto-sensing wrong, and I think it makes sense to correct that behaviour. Let's look what precomposed_unicode does and go through a couple of git operations. 1) When we create a repo under Mac OS using HFS+, we want to have precomposed_unicode = 1 Yes. 2) When we access a repo from Windows/Linux using SAMBA, You mean s/repo/repository that resides on HFS+/? Sorry being unclear here, trying being clearer with an example: I have a /data/Docs on my linux box, which is handled by git I export /data/Docs via SAMBA, and use the Finder under Mac OS to have it mounted on my Mac OS X box: //tb@Linux/Docs on /Volumes/Docs (smbfs, nodev, nosuid, mounted by tb) readdir() will return decomposed. When the repo is created by nonMacOS, core.precomposeunicode is undefined. The precomposition is off, but should be on, precomposed_unicode = -1, but should be = 1 I do not think UTF-8-MAC is widely available; even if you flip the bit on, would it help much? In the above example /data/Docs/.git/config was created by Linux, so it does not have core.precomposeunicode set, neither false nor true. The Linux box does not have UTF-8-MAC under iconv, but will ignore core.precomposeunicode anyway (since the code is not compiled here) The Mac OS machine sees it under /Volumes/Docs/.git/config And here we want the precomposition, even if core.precomposeunicode is not present in the config. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/23] pack v4: initial pack dictionary structure and code
Nicolas Pitre n...@fluxnic.net writes:
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
Was there a reason not to reuse the hash-table Linus did in
hash.[ch]?
It may not make much of a difference for something so small and
isolated from the rest of the system, but if hash.[ch] can be easily
fixed with a small tweak to suit the use by this subsystem better,
it might be worth reusing the existing code with improvement, which
may help other potential users.
packv4-create.c | 137
1 file changed, 137 insertions(+)
create mode 100644 packv4-create.c
diff --git a/packv4-create.c b/packv4-create.c
new file mode 100644
index 000..2de6d41
--- /dev/null
+++ b/packv4-create.c
@@ -0,0 +1,137 @@
+/*
+ * packv4-create.c: management of dictionary tables used in pack v4
+ *
+ * (C) Nicolas Pitre n...@fluxnic.net
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include cache.h
+
+struct data_entry {
+ unsigned offset;
+ unsigned hits;
+};
+
+struct dict_table {
+ char *data;
+ unsigned ptr;
+ unsigned size;
+ struct data_entry *entry;
+ unsigned nb_entries;
+ unsigned max_entries;
+ unsigned *hash;
+ unsigned hash_size;
+};
+
+struct dict_table *create_dict_table(void)
+{
+ return xcalloc(sizeof(struct dict_table), 1);
+}
+
+void destroy_dict_table(struct dict_table *t)
+{
+ free(t-data);
+ free(t-entry);
+ free(t-hash);
+ free(t);
+}
+
+static int locate_entry(struct dict_table *t, const char *str)
+{
+ int i = 0;
+ const unsigned char *s = (const unsigned char *) str;
+
+ while (*s)
+ i = i * 111 + *s++;
+ i = (unsigned)i % t-hash_size;
+
+ while (t-hash[i]) {
+ unsigned n = t-hash[i] - 1;
+ if (!strcmp(str, t-data + t-entry[n].offset))
+ return n;
+ if (++i = t-hash_size)
+ i = 0;
+ }
+ return -1 - i;
+}
+
+static void rehash_entries(struct dict_table *t)
+{
+ unsigned n;
+
+ t-hash_size *= 2;
+ if (t-hash_size 1024)
+ t-hash_size = 1024;
+ t-hash = xrealloc(t-hash, t-hash_size * sizeof(*t-hash));
+ memset(t-hash, 0, t-hash_size * sizeof(*t-hash));
+
+ for (n = 0; n t-nb_entries; n++) {
+ int i = locate_entry(t, t-data + t-entry[n].offset);
+ if (i 0)
+ t-hash[-1 - i] = n + 1;
+ }
+}
+
+int dict_add_entry(struct dict_table *t, const char *str)
+{
+ int i, len = strlen(str) + 1;
+
+ if (t-ptr + len = t-size) {
+ t-size = (t-size + len + 1024) * 3 / 2;
+ t-data = xrealloc(t-data, t-size);
+ }
+ memcpy(t-data + t-ptr, str, len);
+
+ i = (t-nb_entries) ? locate_entry(t, t-data + t-ptr) : -1;
+ if (i = 0) {
+ t-entry[i].hits++;
+ return i;
+ }
+
+ if (t-nb_entries = t-max_entries) {
+ t-max_entries = (t-max_entries + 1024) * 3 / 2;
+ t-entry = xrealloc(t-entry, t-max_entries *
sizeof(*t-entry));
+ }
+ t-entry[t-nb_entries].offset = t-ptr;
+ t-entry[t-nb_entries].hits = 1;
+ t-ptr += len + 1;
+ t-nb_entries++;
+
+ if (t-hash_size * 3 = t-nb_entries * 4)
+ rehash_entries(t);
+ else
+ t-hash[-1 - i] = t-nb_entries;
+
+ return t-nb_entries - 1;
+}
+
+static int cmp_dict_entries(const void *a_, const void *b_)
+{
+ const struct data_entry *a = a_;
+ const struct data_entry *b = b_;
+ int diff = b-hits - a-hits;
+ if (!diff)
+ diff = a-offset - b-offset;
+ return diff;
+}
+
+static void sort_dict_entries_by_hits(struct dict_table *t)
+{
+ qsort(t-entry, t-nb_entries, sizeof(*t-entry), cmp_dict_entries);
+ t-hash_size = (t-nb_entries * 4 / 3) / 2;
+ rehash_entries(t);
+}
+
+void dict_dump(struct dict_table *t)
+{
+ int i;
+
+ sort_dict_entries_by_hits(t);
+ for (i = 0; i t-nb_entries; i++)
+ printf(%d\t%s\n,
+ t-entry[i].hits,
+ t-data + t-entry[i].offset);
+}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Eclipse
Does git work with Eclipse? Ron -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Eclipse
On 27.08.13 17:10, Ron Tregaskis - NOAA Federal wrote: Does git work with Eclipse? No. If the question is does Eclipse work with git: yes. For more information please feel free to spend some seconds using a seach engine. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/23] pack v4: add commit object parsing
Nicolas Pitre n...@fluxnic.net writes:
Let's create another dictionary table to hold the author and committer
entries. We use the same table format used for tree entries where the
16 bit data prefix is conveniently used to store the timezone value.
In order to copy straight from a commit object buffer, dict_add_entry()
is modified to get the string length as the provided string pointer is
not always be null terminated.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
@@ -135,8 +136,73 @@ static void sort_dict_entries_by_hits(struct dict_table
*t)
rehash_entries(t);
}
+static struct dict_table *commit_name_table;
static struct dict_table *tree_path_table;
+/*
+ * Parse the author/committer line from a canonical commit object.
+ * The 'from' argument points right after the author or committer
+ * string. The time zone is parsed and stored in *tz_val. The returned
+ * pointer is right after the end of the email address which is also just
+ * before the time value, or NULL if a parsing error is encountered.
+ */
+static char *get_nameend_and_tz(char *from, int *tz_val)
+{
+ char *end, *tz;
+
+ tz = strchr(from, '\n');
+ /* let's assume the smallest possible string to be x x 0 +\n */
+ if (!tz || tz - from 13)
+ return NULL;
+ tz -= 4;
+ end = tz - 4;
+ while (end - from 5 *end != ' ')
+ end--;
+ if (end[-1] != '' || end[0] != ' ' || tz[-2] != ' ')
+ return NULL;
+ *tz_val = (tz[0] - '0') * 1000 +
+ (tz[1] - '0') * 100 +
+ (tz[2] - '0') * 10 +
+ (tz[3] - '0');
+ switch (tz[-1]) {
+ default:return NULL;
+ case '+': break;
+ case '-': *tz_val = -*tz_val;
+ }
+ return end;
+}
This may want to share code with ident.c::split_ident_line(), as we
have been trying to reduce the number of ident-line parsers.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/23] pack v4: basic references encoding
Nicolas Pitre n...@fluxnic.net writes:
Add variable length number encoding. Let's apply the same encoding
currently used for the offset to base of OBJ_OFS_DELTA objects which
is the most efficient way to do this, and apply it to everything with
pack version 4.
Also add SHA1 reference encoding. This one is either an index into a
SHA1 table encoded using the variable length number encoding, or the
literal 20 bytes SHA1 prefixed with a 0.
The index 0 discriminates between an actual index value or the literal
SHA1. Therefore when the index is used its value must be increased by 1.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 44
1 file changed, 44 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index 012129b..bf33d15 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -245,6 +245,50 @@ static void dict_dump(void)
dump_dict_table(tree_path_table);
}
+/*
+ * Encode a numerical value with variable length into the destination buffer
+ */
+static unsigned char *add_number(unsigned char *dst, uint64_t value)
+{
+ unsigned char buf[20];
+ unsigned pos = sizeof(buf) - 1;
+ buf[pos] = value 127;
+ while (value = 7)
+ buf[--pos] = 128 | (--value 127);
+ do {
+ *dst++ = buf[pos++];
+ } while (pos sizeof(buf));
+ return dst;
+}
This may want to reuse (or enhance-then-reuse) varint.[ch].
+/*
+ * Encode an object SHA1 reference with either an object index into the
+ * pack SHA1 table incremented by 1, or the literal SHA1 value prefixed
+ * with a zero byte if the needed SHA1 is not available in the table.
+ */
+static struct pack_idx_entry *all_objs;
+static unsigned all_objs_nr;
+static unsigned char *add_sha1_ref(unsigned char *dst, const unsigned char
*sha1)
+{
+ unsigned lo = 0, hi = all_objs_nr;
+
+ do {
+ unsigned mi = (lo + hi) / 2;
+ int cmp = hashcmp(all_objs[mi].sha1, sha1);
+
+ if (cmp == 0)
+ return add_number(dst, mi + 1);
+ if (cmp 0)
+ hi = mi;
+ else
+ lo = mi+1;
+ } while (lo hi);
+
+ *dst++ = 0;
+ hashcpy(dst, sha1);
+ return dst + 20;
+}
+
static struct pack_idx_entry *get_packed_object_list(struct packed_git *p)
{
unsigned i, nr_objects = p-num_objects;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/23] pack v4: commit object encoding
Nicolas Pitre n...@fluxnic.net writes:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
add_sha1_ref()).
- Parent count: variable length encoding of the number of parents.
This is normally going to occupy a single byte but doesn't have to.
- List of parent references: a list of add_sha1_ref() encoded references,
or nothing if the parent count was zero.
- Author reference: variable length encoding of an index into the author
string dictionary table which also covers the time zone. To make the
overall encoding efficient, the author table is already sorted by usage
frequency so the most used names are first and require the shortest
index encoding.
- Author time stamp: variable length encoded. Year 2038 ready!
- Committer reference: same as author reference.
- Committer time stamp: same as author time stamp.
The remainder of the canonical commit object content is then zlib
compressed and appended to the above.
Rationale: The most important commit object data is densely encoded while
requiring no zlib inflate processing, and all SHA1 references are most
likely to be direct indices into the pack index file requiring no SHA1
search into the pack index file.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 119
1 file changed, 119 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index bf33d15..cedbbd9 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -13,6 +13,9 @@
#include tree-walk.h
#include pack.h
+
+static int pack_compression_level = Z_DEFAULT_COMPRESSION;
+
struct data_entry {
unsigned offset;
unsigned size;
@@ -289,6 +292,122 @@ static unsigned char *add_sha1_ref(unsigned char *dst,
const unsigned char *sha1
return dst + 20;
}
+/*
+ * This converts a canonical commit object buffer into its
+ * tightly packed representation using the already populated
+ * and sorted commit_name_table dictionary. The parsing is
+ * strict so to ensure the canonical version may always be
+ * regenerated and produce the same hash.
+ */
+void * conv_to_dict_commit(void *buffer, unsigned long *psize)
Drop SP between asterisk and conv_?
+{
+ unsigned long size = *psize;
+ char *in, *tail, *end;
+ unsigned char *out;
+ unsigned char sha1[20];
+ int nb_parents, index, tz_val;
+ unsigned long time;
+ z_stream stream;
+ int status;
+
+ /*
+ * It is guaranteed that the output is always going to be smaller
+ * than the input. We could even do this conversion in place.
+ */
+ in = buffer;
+ tail = in + size;
+ buffer = xmalloc(size);
+ out = buffer;
+
+ /* parse the tree line */
+ if (in + 46 = tail || memcmp(in, tree , 5) || in[45] != '\n')
+ goto bad_data;
+ if (get_sha1_hex(in + 5, sha1) 0)
+ goto bad_data;
Is this strict enough to guarantee roundtrip hash identity? Because
get_sha1_hex() accepts hexadecimal represented with uppercase A-F,
you need to reject such a broken commit object, no?
Same for parent commit object names below that are parsed with the
same helper.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/23] pack v4: tree object encoding
Nicolas Pitre n...@fluxnic.net writes:
This goes as follows:
- Number of tree entries: variable length encoded.
Then for each tree entry:
- Path component reference: variable length encoded index into the path
string dictionary table which also covers the entry mode. To make the
overall encoding efficient, the author table is already sorted by usage
frequency so the most used names are first and require the shortest
index encoding.
s/author table/tree path table/, I think. The reason why it is a
good idea to sort these tables by use count applies equally to both
the author table and the tree path table, though.
- SHA1 reference: either variable length encoding of the index into the
SHA1 table or the literal SHA1 prefixed by 0 (see add_sha1_ref()).
Rationale: all the tree object data is densely encoded while requiring
no zlib inflate processing, and all SHA1 references are most likely to
be direct indices into the pack index file requiring no SHA1 search.
Path filtering can be accomplished on the path index directly without
any string comparison during the tree traversal.
Still lacking is some kind of delta encoding for multiple tree objects
with only small differences between them. But that'll come later.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 63
+
1 file changed, 63 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index cedbbd9..f46fbd9 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -408,6 +408,69 @@ bad:
return NULL;
}
+/*
+ * This converts a canonical tree object buffer into its
+ * tightly packed representation using the already populated
+ * and sorted tree_path_table dictionary. The parsing is
+ * strict so to ensure the canonical version may always be
+ * regenerated and produce the same hash.
+ */
+void * conv_to_dict_tree(void *buffer, unsigned long *psize)
+{
+ unsigned long size = *psize;
+ unsigned char *in, *out, *end;
+ struct tree_desc desc;
+ struct name_entry name_entry;
+ int nb_entries;
+
+ if (!size)
+ return NULL;
+
+ /*
+ * We can't make sure the result will always be smaller.
+ * The smallest possible entry is 0 x\040 byte SHA1
+ * or 44 bytes. The output entry may have a realistic path index
+ * encoding using up to 3 bytes, and a non indexable SHA1 meaning
+ * 41 bytes. And the output data already has the and nb_entries
+ * headers. In practice the output size will be significantly
+ * smaller but for now let's make it simple.
+ */
+ in = buffer;
+ out = xmalloc(size);
+ end = out + size;
+ buffer = out;
+
+ /* let's count how many entries there are */
+ init_tree_desc(desc, in, size);
+ nb_entries = 0;
+ while (tree_entry(desc, name_entry))
+ nb_entries++;
+ out = add_number(out, nb_entries);
+
+ init_tree_desc(desc, in, size);
+ while (tree_entry(desc, name_entry)) {
+ int pathlen = tree_entry_len(name_entry);
+ int index = dict_add_entry(tree_path_table, name_entry.mode,
+name_entry.path, pathlen);
+ if (index 0) {
+ error(missing tree dict entry);
+ free(buffer);
+ return NULL;
+ }
+ if (end - out 45) {
+ unsigned long sofar = out - (unsigned char *)buffer;
+ buffer = xrealloc(buffer, sofar + 45);
+ out = (unsigned char *)buffer + sofar;
+ end = out + 45;
+ }
+ out = add_number(out, index);
+ out = add_sha1_ref(out, name_entry.sha1);
+ }
+
+ *psize = out - (unsigned char *)buffer;
+ return buffer;
+}
+
static struct pack_idx_entry *get_packed_object_list(struct packed_git *p)
{
unsigned i, nr_objects = p-num_objects;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/23] pack v4: creation code
Nicolas Pitre n...@fluxnic.net writes:
Let's actually open the destination pack file and write the header and
the tables.
The header isn't much different from pack v3, except for the pack version
number of course.
The first table is the sorted SHA1 table normally found in the pack index
file. With pack v4 we write this table in the main pack file instead as
it is index referenced by subsequent objects in the pack. Doing so has
many advantages:
- The SHA1 references used to be duplicated on disk: once in the pack
index file, and then at least once or more within commit and tree
objects referencing them. The only SHA1 which is not being listed more
than once this way is the one for a branch tip commit object and those
are normally very few. Now all that SHA1 data is represented only once.
This tickles my curiosity. Why isn't this SHA-1 table sorted by
reference count the same way as the tree path and the people name
tables to keep the average length of varint references short?
- The SHA1 references found in commit and tree objects can be obtained
on disk directly without having to deflate those objects first.
The SHA1 table size is obtained by multiplying the number of objects by 20.
And then the commit and path dictionary tables are written right after
the SHA1 table.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 60
-
1 file changed, 55 insertions(+), 5 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index 2956fda..5211f9c 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -605,6 +605,48 @@ static unsigned long write_dict_table(struct sha1file
*f, struct dict_table *t)
return hdrlen + datalen;
}
+static struct sha1file * packv4_open(char *path)
+{
+ int fd;
+
+ fd = open(path, O_CREAT|O_EXCL|O_WRONLY, 0600);
+ if (fd 0)
+ die_errno(unable to create '%s', path);
+ return sha1fd(fd, path);
+}
+
+static unsigned int packv4_write_header(struct sha1file *f, unsigned
nr_objects)
+{
+ struct pack_header hdr;
+
+ hdr.hdr_signature = htonl(PACK_SIGNATURE);
+ hdr.hdr_version = htonl(4);
+ hdr.hdr_entries = htonl(nr_objects);
+ sha1write(f, hdr, sizeof(hdr));
+
+ return sizeof(hdr);
+}
+
+static unsigned long packv4_write_tables(struct sha1file *f, unsigned
nr_objects,
+ struct pack_idx_entry *objs)
+{
+ unsigned i;
+ unsigned long written = 0;
+
+ /* The sorted list of object SHA1's is always first */
+ for (i = 0; i nr_objects; i++)
+ sha1write(f, objs[i].sha1, 20);
+ written = 20 * nr_objects;
+
+ /* Then the commit dictionary table */
+ written += write_dict_table(f, commit_name_table);
+
+ /* Followed by the path component dictionary table */
+ written += write_dict_table(f, tree_path_table);
+
+ return written;
+}
+
static struct packed_git *open_pack(const char *path)
{
char arg[PATH_MAX];
@@ -658,9 +700,10 @@ static struct packed_git *open_pack(const char *path)
return p;
}
-static void process_one_pack(char *src_pack)
+static void process_one_pack(char *src_pack, char *dst_pack)
{
struct packed_git *p;
+ struct sha1file *f;
struct pack_idx_entry *objs, **p_objs;
unsigned nr_objects;
@@ -673,15 +716,22 @@ static void process_one_pack(char *src_pack)
p_objs = sort_objs_by_offset(objs, nr_objects);
create_pack_dictionaries(p, p_objs);
+
+ f = packv4_open(dst_pack);
+ if (!f)
+ die(unable to open destination pack);
+ packv4_write_header(f, nr_objects);
+ packv4_write_tables(f, nr_objects, objs);
}
int main(int argc, char *argv[])
{
- if (argc != 2) {
- fprintf(stderr, Usage: %s packfile\n, argv[0]);
+ if (argc != 3) {
+ fprintf(stderr, Usage: %s src_packfile dst_packfile\n,
argv[0]);
exit(1);
}
- process_one_pack(argv[1]);
- dict_dump();
+ process_one_pack(argv[1], argv[2]);
+ if (0)
+ dict_dump();
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/23] pack v4: basic references encoding
On Tue, 27 Aug 2013, Junio C Hamano wrote:
Nicolas Pitre n...@fluxnic.net writes:
Add variable length number encoding. Let's apply the same encoding
currently used for the offset to base of OBJ_OFS_DELTA objects which
is the most efficient way to do this, and apply it to everything with
pack version 4.
Also add SHA1 reference encoding. This one is either an index into a
SHA1 table encoded using the variable length number encoding, or the
literal 20 bytes SHA1 prefixed with a 0.
The index 0 discriminates between an actual index value or the literal
SHA1. Therefore when the index is used its value must be increased by 1.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 44
1 file changed, 44 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index 012129b..bf33d15 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -245,6 +245,50 @@ static void dict_dump(void)
dump_dict_table(tree_path_table);
}
+/*
+ * Encode a numerical value with variable length into the destination
buffer
+ */
+static unsigned char *add_number(unsigned char *dst, uint64_t value)
+{
+ unsigned char buf[20];
+ unsigned pos = sizeof(buf) - 1;
+ buf[pos] = value 127;
+ while (value = 7)
+ buf[--pos] = 128 | (--value 127);
+ do {
+ *dst++ = buf[pos++];
+ } while (pos sizeof(buf));
+ return dst;
+}
This may want to reuse (or enhance-then-reuse) varint.[ch].
Goodie! I didn't notice this had happened.
Nicolas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/23] pack v4: object data copy
Nicolas Pitre n...@fluxnic.net writes:
Blob and tag objects have no particular changes except for their object
header.
Delta objects are also copied as is, except for their delta base reference
which is converted to the new way as used elsewhere in pack v4 encoding
i.e. an index into the SHA1 table or a literal SHA1 prefixed by 0 if not
found in the table (see add_sha1_ref). This is true for both REF_DELTA
as well as OFS_DELTA.
Object payload is validated against the recorded CRC32 in the source
pack index file when possible.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
The title somewhat confused me until I realized that this series is
building a program that would convert existing data from a single
pack into packv4 format, not a pack-objects --pack-verison=4.
packv4-create.c | 66
+
1 file changed, 66 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index 6e0bb1d..a6dc818 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -12,6 +12,7 @@
#include object.h
#include tree-walk.h
#include pack.h
+#include pack-revindex.h
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
@@ -673,6 +674,71 @@ static unsigned int write_object_header(struct sha1file
*f, enum object_type typ
return end - buf;
}
+static unsigned long copy_object_data(struct sha1file *f, struct packed_git
*p,
+ off_t offset)
+{
+ struct pack_window *w_curs = NULL;
+ struct revindex_entry *revidx;
+ enum object_type type;
+ unsigned long avail, size, datalen, written;
+ int hdrlen, idx_nr;
+ unsigned char *src, *end, buf[24];
+
+ revidx = find_pack_revindex(p, offset);
+ idx_nr = revidx-nr;
+ datalen = revidx[1].offset - offset;
+
+ src = use_pack(p, w_curs, offset, avail);
+ hdrlen = unpack_object_header_buffer(src, avail, type, size);
+
+ written = write_object_header(f, type, size);
+
+ if (type == OBJ_OFS_DELTA) {
+ unsigned char c = src[hdrlen++];
+ off_t base_offset = c 127;
+ while (c 128) {
+ base_offset += 1;
+ if (!base_offset || MSB(base_offset, 7))
+ die(delta offset overflow);
+ c = src[hdrlen++];
+ base_offset = (base_offset 7) + (c 127);
+ }
+ base_offset = offset - base_offset;
+ if (base_offset = 0 || base_offset = offset)
+ die(delta offset out of bound);
+ revidx = find_pack_revindex(p, base_offset);
+ end = add_sha1_ref(buf, nth_packed_object_sha1(p, revidx-nr));
+ sha1write(f, buf, end - buf);
+ written += end - buf;
+ } else if (type == OBJ_REF_DELTA) {
+ end = add_sha1_ref(buf, src + hdrlen);
+ hdrlen += 20;
+ sha1write(f, buf, end - buf);
+ written += end - buf;
+ }
+
+ if (p-index_version 1
+ check_pack_crc(p, w_curs, offset, datalen, idx_nr))
+ die(bad CRC for object at offset %PRIuMAX in %s,
+ (uintmax_t)offset, p-pack_name);
+
+ offset += hdrlen;
+ datalen -= hdrlen;
+
+ while (datalen) {
+ src = use_pack(p, w_curs, offset, avail);
+ if (avail datalen)
+ avail = datalen;
+ sha1write(f, src, avail);
+ written += avail;
+ offset += avail;
+ datalen -= avail;
+ }
+ unuse_pack(w_curs);
+
+ return written;
+}
+
static struct packed_git *open_pack(const char *path)
{
char arg[PATH_MAX];
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] Preliminary pack v4 support
On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: Subject says it all... at last ! This can also be fetched here: git://git.linaro.org/people/nico/git Demonstration of what it does at the moment: http://article.gmane.org/gmane.comp.version-control.git/233038 I'd like to preserve the author time stamps as they relate to where in the world I was when the corresponding code was written. You'll notice I didn't work on the code in the same order as it is now presented. We can also notice things like From: user@machine.(none) ;-) Heh. Still open question: what to do with a thin pack. Should we really complete it with local objects upon reception, or were we only over paranoid at the time we imposed this rule? I do not think paranoia had much to do with it. I am afraid that allowing a delta in a pack to depend on a base in another pack means that the former pack becomes unusable without the latter, which would make object store management (e.g. partial repacking) a lot more cumbersome, no? That's what I'm wondering. We already end up with a broken repository if the commit graph is spread across multiple packs and one of those pack is removed. Having a delta base in a separate pack is not much different in that regard. So the rule could be that any kind of repacking must not carry over deltas with a non local base i.e. repack always produces delta references belonging to the same pack. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/23] pack v4: initial pack dictionary structure and code
On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: Signed-off-by: Nicolas Pitre n...@fluxnic.net --- Was there a reason not to reuse the hash-table Linus did in hash.[ch]? Well... Most likely because when I started that code (which used to be quite different initially) it might not have been served correctly by hash.c, or any other reasons I long have forgotten by now which might or might not still be valid. It may not make much of a difference for something so small and isolated from the rest of the system, but if hash.[ch] can be easily fixed with a small tweak to suit the use by this subsystem better, it might be worth reusing the existing code with improvement, which may help other potential users. Absolutely. If someone wants to give a hand in that direction I'll happily integrate patches into my series. I cannot promise I'll do the work myself as I prefer spending the time I have available on actually making pack v4 usable. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] core.precomposeunicode is true by default
Torsten Bögershausen tbo...@web.de writes: 2) When we access a repo from Windows/Linux using SAMBA, You mean s/repo/repository that resides on HFS+/? Sorry being unclear here, trying being clearer with an example: I have a /data/Docs on my linux box, which is handled by git I export /data/Docs via SAMBA, and use the Finder under Mac OS to have it mounted on my Mac OS X box: //tb@Linux/Docs on /Volumes/Docs (smbfs, nodev, nosuid, mounted by tb) readdir() will return decomposed. When the repo is created by nonMacOS, core.precomposeunicode is undefined. The precomposition is off, but should be on, precomposed_unicode = -1, but should be = 1 I do not think UTF-8-MAC is widely available; even if you flip the bit on, would it help much? In the above example /data/Docs/.git/config was created by Linux, so it does not have core.precomposeunicode set, neither false nor true. The Linux box does not have UTF-8-MAC under iconv, but will ignore core.precomposeunicode anyway (since the code is not compiled here) The Mac OS machine sees it under /Volumes/Docs/.git/config And here we want the precomposition, even if core.precomposeunicode is not present in the config. It almost makes me wonder if you want not a per-repository but a per-machine configuration, i.e. Whichever repository I am accessing, either on a local filesystem or shared over the network, readdir() on my box reports wrong paths, and I need correction. That, or if it hurts, don't do the remote mount then. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: clarify notes for clean.requireForce
Jiang Xin worldhello@gmail.com writes: Add -i (interactive clean option) to clarify the documentation for clean.requireForce config variable. Also replace the example in `gitcli.txt` with safer git clean command. Hmm, the former change may make sense, but I am not sure about the latter. The section is about showing examples of concatenating command line options, and I find it far more appropriate to use clean -f, which is a lot more widely known than clean -i, for the intended audience, those who are learning how to compose the command line options. Signed-off-by: Jiang Xin worldhello@gmail.com --- Documentation/config.txt | 4 ++-- Documentation/gitcli.txt | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8361380..547149d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -795,8 +795,8 @@ browser.tool.path:: working repository in gitweb (see linkgit:git-instaweb[1]). clean.requireForce:: - A boolean to make git-clean do nothing unless given -f - or -n. Defaults to true. + A boolean to make git-clean do nothing unless given -i, + -f or -n. Defaults to true. color.branch:: A boolean to enable/disable color in the output of diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 9ac5088..4005a3b 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -135,7 +135,7 @@ Aggregating short options ~ Commands that support the enhanced option parser allow you to aggregate short options. This means that you can for example use `git rm -rf` or -`git clean -fdx`. +`git clean -idx`. Abbreviating long options -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] Preliminary pack v4 support
Nicolas Pitre n...@fluxnic.net writes: On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: ... I'd like to preserve the author time stamps as they relate to where in the world I was when the corresponding code was written. You'll notice I didn't work on the code in the same order as it is now presented. We can also notice things like From: user@machine.(none) ;-) Heh. In any case, the Date: in-body header next to your From: in-body header is your friend if you want to do the where and when did I work on this? Still open question: what to do with a thin pack. Should we really complete it with local objects upon reception, or were we only over paranoid at the time we imposed this rule? I do not think paranoia had much to do with it. I am afraid that allowing a delta in a pack to depend on a base in another pack means that the former pack becomes unusable without the latter, which would make object store management (e.g. partial repacking) a lot more cumbersome, no? That's what I'm wondering. We already end up with a broken repository if the commit graph is spread across multiple packs and one of those pack is removed. Having a delta base in a separate pack is not much different in that regard. In practice, maybe, but I somehow find that it is more fundamental breakage not to be able to reconstitute objects that a pack and its index claims to have than missing an object that is referenced in the reachability graph. As you have 0-index escape hatch for SHA-1 table, but no similar escape hatch for the people's name table, I can see why it may be cumbersome to fix a thin pack by only appending to a received packfile and updating a few header fields, though. So the rule could be that any kind of repacking must not carry over deltas with a non local base i.e. repack always produces delta references belonging to the same pack. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/23] pack v4: add commit object parsing
On Tue, 27 Aug 2013, Junio C Hamano wrote:
Nicolas Pitre n...@fluxnic.net writes:
Let's create another dictionary table to hold the author and committer
entries. We use the same table format used for tree entries where the
16 bit data prefix is conveniently used to store the timezone value.
In order to copy straight from a commit object buffer, dict_add_entry()
is modified to get the string length as the provided string pointer is
not always be null terminated.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
@@ -135,8 +136,73 @@ static void sort_dict_entries_by_hits(struct
dict_table *t)
rehash_entries(t);
}
+static struct dict_table *commit_name_table;
static struct dict_table *tree_path_table;
+/*
+ * Parse the author/committer line from a canonical commit object.
+ * The 'from' argument points right after the author or committer
+ * string. The time zone is parsed and stored in *tz_val. The returned
+ * pointer is right after the end of the email address which is also just
+ * before the time value, or NULL if a parsing error is encountered.
+ */
+static char *get_nameend_and_tz(char *from, int *tz_val)
+{
+ char *end, *tz;
+
+ tz = strchr(from, '\n');
+ /* let's assume the smallest possible string to be x x 0 +\n */
+ if (!tz || tz - from 13)
+ return NULL;
+ tz -= 4;
+ end = tz - 4;
+ while (end - from 5 *end != ' ')
+ end--;
+ if (end[-1] != '' || end[0] != ' ' || tz[-2] != ' ')
+ return NULL;
+ *tz_val = (tz[0] - '0') * 1000 +
+ (tz[1] - '0') * 100 +
+ (tz[2] - '0') * 10 +
+ (tz[3] - '0');
+ switch (tz[-1]) {
+ default:return NULL;
+ case '+': break;
+ case '-': *tz_val = -*tz_val;
+ }
+ return end;
+}
This may want to share code with ident.c::split_ident_line(), as we
have been trying to reduce the number of ident-line parsers.
Hmmm The problem I have with split_ident_line() right now is about
the fact that it is too liberal with whitespaces. Here I must be sure I
can deconstruct a commit object and be sure I still can regenerate it
byte for byte in order to match its SHA1 signature.
So there _must_ always be only one space between the email closing
bracket and the time stamp, only one space between the time stamp and
the time zone value, and no space after the time zone.
Is there a reason why split_ident_line() is not stricter in that regard?
Nicolas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/23] pack v4: commit object encoding
On Tue, 27 Aug 2013, Junio C Hamano wrote:
Nicolas Pitre n...@fluxnic.net writes:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
add_sha1_ref()).
- Parent count: variable length encoding of the number of parents.
This is normally going to occupy a single byte but doesn't have to.
- List of parent references: a list of add_sha1_ref() encoded references,
or nothing if the parent count was zero.
- Author reference: variable length encoding of an index into the author
string dictionary table which also covers the time zone. To make the
overall encoding efficient, the author table is already sorted by usage
frequency so the most used names are first and require the shortest
index encoding.
- Author time stamp: variable length encoded. Year 2038 ready!
- Committer reference: same as author reference.
- Committer time stamp: same as author time stamp.
The remainder of the canonical commit object content is then zlib
compressed and appended to the above.
Rationale: The most important commit object data is densely encoded while
requiring no zlib inflate processing, and all SHA1 references are most
likely to be direct indices into the pack index file requiring no SHA1
search into the pack index file.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 119
1 file changed, 119 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index bf33d15..cedbbd9 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -13,6 +13,9 @@
#include tree-walk.h
#include pack.h
+
+static int pack_compression_level = Z_DEFAULT_COMPRESSION;
+
struct data_entry {
unsigned offset;
unsigned size;
@@ -289,6 +292,122 @@ static unsigned char *add_sha1_ref(unsigned char
*dst, const unsigned char *sha1
return dst + 20;
}
+/*
+ * This converts a canonical commit object buffer into its
+ * tightly packed representation using the already populated
+ * and sorted commit_name_table dictionary. The parsing is
+ * strict so to ensure the canonical version may always be
+ * regenerated and produce the same hash.
+ */
+void * conv_to_dict_commit(void *buffer, unsigned long *psize)
Drop SP between asterisk and conv_?
+{
+ unsigned long size = *psize;
+ char *in, *tail, *end;
+ unsigned char *out;
+ unsigned char sha1[20];
+ int nb_parents, index, tz_val;
+ unsigned long time;
+ z_stream stream;
+ int status;
+
+ /*
+* It is guaranteed that the output is always going to be smaller
+* than the input. We could even do this conversion in place.
+*/
+ in = buffer;
+ tail = in + size;
+ buffer = xmalloc(size);
+ out = buffer;
+
+ /* parse the tree line */
+ if (in + 46 = tail || memcmp(in, tree , 5) || in[45] != '\n')
+ goto bad_data;
+ if (get_sha1_hex(in + 5, sha1) 0)
+ goto bad_data;
Is this strict enough to guarantee roundtrip hash identity? Because
get_sha1_hex() accepts hexadecimal represented with uppercase A-F,
you need to reject such a broken commit object, no?
Indeed, yes. Same concern as with split_ident_line() I mentioned
before.
Same for parent commit object names below that are parsed with the
same helper.
Exact.
Nicolas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Eclipse
On 8/27/2013 10:10 AM, Ron Tregaskis - NOAA Federal wrote: Does git work with Eclipse? Ron -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I find that an interesting question as I am considering switching from SVN to GIT for a new Android project. This looks like a good place to start: https://github.com/blog/1181-eclipse-git-plugin-2-0-released -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/23] pack v4: add commit object parsing
Nicolas Pitre n...@fluxnic.net writes: Hmmm The problem I have with split_ident_line() right now is about the fact that it is too liberal with whitespaces. Here I must be sure I can deconstruct a commit object and be sure I still can regenerate it byte for byte in order to match its SHA1 signature. Yeah, I now see. It's the same accept with leniency get_sha1_hex() does, which is not appropriate for the purpose of this codepath. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/11] Modernize user-manual
Hi, this is v2 of my patches for user-manual.txt. Thanks to Junio, Jonathan, Martin and Philip for your comments! I think Philips remarks should be part of a separate patch series which then also should address the current differences in layout between user-manual.html and user-manual.pdf. Changes in v2: [PATCH 01/13] Call it Git User Manual and remove reference to very old Git version - same as v1 [PATCH 02/13] Use current detached HEAD message - fixed another occurence of (no branch) [PATCH 03/13] Use current output for git repack - add location where packfile is created [PATCH 04/13] Use git merge instead of git pull . - reverted changes in Getting updates with git pull [PATCH 05/13] Fix some typos and improve wording - better wording [PATCH 06/13] Simplify How to make a commit - better wording [PATCH 07/13] Improve description in How to merge - this patch was dropped [PATCH 08/13] Improve section Manipulating branches - add missing case for current [PATCH 09/13] Improve section Merge multiple trees - better wording [PATCH 10/13] Remove unnecessary historical note from Object storage format - same as in v1 [PATCH 11/13] Remove obscure reference from Examples - this patch was dropped [PATCH 12/13] Remove irrelevant reference from Tying it all together - same as in v1 [PATCH 13/13] git prune is safe now - weakend warning for git prune Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] Call it Git User Manual and remove reference to very old Git version
Reviewed-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index fe723e4..103ec9a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1,6 +1,5 @@ -Git User's Manual (for version 1.5.3 or newer) -__ - +Git User Manual +___ Git is a fast distributed revision control system. -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] Use current detached HEAD message
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 103ec9a..bdefd9a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -312,10 +312,17 @@ referenced by a tag: $ git checkout v2.6.17 -Note: moving to v2.6.17 which isn't a local branch -If you want to create a new branch from this checkout, you may do so -(now or later) by using -b with the checkout command again. Example: - git checkout -b new_branch_name +Note: checking out 'v2.6.17'. + +You are in 'detached HEAD' state. You can look around, make experimental +changes and commit them, and you can discard any commits you make in this +state without impacting any branches by performing another checkout. + +If you want to create a new branch to retain commits you create, you may +do so (now or later) by using -b with the checkout command again. Example: + + git checkout -b new_branch_name + HEAD is now at 427abfa... Linux v2.6.17 @@ -326,7 +333,7 @@ and git branch shows that you are no longer on a branch: $ cat .git/HEAD 427abfa28afedffadfca9dd8b067eb6d36bac53f $ git branch -* (no branch) +* (detached from v2.6.17) master @@ -3639,7 +3646,7 @@ working on a branch. - $ git branch -* (no branch) +* (detached from d266b98) master - -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] Use current output for git repack
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index bdefd9a..3f44ca0 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3203,17 +3203,15 @@ To put the loose objects into a pack, just run git repack: $ git repack -Generating pack... -Done counting 6020 objects. -Deltifying 6020 objects. - 100% (6020/6020) done -Writing 6020 objects. - 100% (6020/6020) done -Total 6020, written 6020 (delta 4070), reused 0 (delta 0) -Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created. +Counting objects: 6020, done. +Delta compression using up to 4 threads. +Compressing objects: 100% (6020/6020), done. +Writing objects: 100% (6020/6020), done. +Total 6020 (delta 4070), reused 0 (delta 0) -You can then run +This creates a single pack file in .git/objects/pack/ +containing all currently unpacked objects. You can then run $ git prune -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] Use git merge instead of git pull .
git pull . works, but git merge is the recommended way for new users to do things. (The old description also should have read The former is actually *not* very commonly used.) Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 3f44ca0..6241a43 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1793,7 +1793,7 @@ $ git pull . branch $ git merge branch - -are roughly equivalent. The former is actually very commonly used. +are roughly equivalent. [[submitting-patches]] Submitting patches to a project @@ -2255,11 +2255,11 @@ commit to this branch. $ ... patch ... test ... commit [ ... patch ... test ... commit ]* - -When you are happy with the state of this change, you can pull it into the +When you are happy with the state of this change, you can merge it into the test branch in preparation to make it public: - -$ git checkout test git pull . speed-up-spinlocks +$ git checkout test git merge speed-up-spinlocks - It is unlikely that you would have any conflicts here ... but you might if you @@ -2271,7 +2271,7 @@ see the value of keeping each patch (or patch series) in its own branch. It means that the patches can be moved into the `release` tree in any order. - -$ git checkout release git pull . speed-up-spinlocks +$ git checkout release git merge speed-up-spinlocks - After a while, you will have a number of branches, and despite the -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] Fix some typos and improve wording
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 6241a43..465d9cb 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -219,7 +219,7 @@ of development leading to that point. The best way to see how this works is using the linkgit:gitk[1] command; running gitk now on a Git repository and looking for merge -commits will help understand how the Git organizes history. +commits will help understand how Git organizes history. In the following, we say that commit X is reachable from commit Y if commit X is an ancestor of commit Y. Equivalently, you could say @@ -793,7 +793,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b - Or you could recall that the `...` operator selects all commits -contained reachable from either one reference or the other but not +reachable from either one reference or the other but not both; so - @@ -820,7 +820,7 @@ You could just visually inspect the commits since e05db0fd: $ gitk e05db0fd.. - -Or you can use linkgit:git-name-rev[1], which will give the commit a +or you can use linkgit:git-name-rev[1], which will give the commit a name based on any tag it finds pointing to one of the commit's descendants: @@ -864,8 +864,8 @@ because it outputs only commits that are not reachable from v1.5.0-rc1. As yet another alternative, the linkgit:git-show-branch[1] command lists the commits reachable from its arguments with a display on the left-hand -side that indicates which arguments that commit is reachable from. So, -you can run something like +side that indicates which arguments that commit is reachable from. +So, if you run something like - $ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2 @@ -877,15 +877,15 @@ available ... - -then search for a line that looks like +then a line like - + ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if available - -Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and -from v1.5.0-rc2, but not from v1.5.0-rc0. +shows that e05db0fd is reachable from itself, from v1.5.0-rc1, +and from v1.5.0-rc2, and not from v1.5.0-rc0. [[showing-commits-unique-to-a-branch]] Showing commits unique to a given branch @@ -3542,7 +3542,7 @@ with Git 1.5.2 can look up the submodule commits in the repository and manually check them out; earlier versions won't recognize the submodules at all. -To see how submodule support works, create (for example) four example +To see how submodule support works, create four example repositories that can be used later as a submodule: - @@ -3914,7 +3914,7 @@ fact that such a commit brings together (merges) two or more previous states represented by other commits. In other words, while a tree represents a particular directory state -of a working directory, a commit represents that state in time, +of a working directory, a commit represents that state in time, and explains how we got there. You create a commit object by giving it the tree that describes the -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] Improve section Manipulating branches
Add some missing punctuation. Simplify description of git branch -d/-D. Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 98d2804..c20e8df 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -268,27 +268,23 @@ Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands: `git branch`:: - list all branches + list all branches. `git branch branch`:: create a new branch named `branch`, referencing the same - point in history as the current branch + point in history as the current branch. `git branch branch start-point`:: create a new branch named `branch`, referencing `start-point`, which may be specified any way you like, - including using a branch name or a tag name + including using a branch name or a tag name. `git branch -d branch`:: - delete the branch `branch`; if the branch you are deleting - points to a commit which is not reachable from the current - branch, this command will fail with a warning. + delete the branch `branch`; if the branch is not fully + merged in its upstream branch or contained in the current branch, + this command will fail with a warning. `git branch -D branch`:: - even if the branch points to a commit not reachable - from the current branch, you may know that that commit - is still reachable from some other branch or tag. In that - case it is safe to use this command to force Git to delete - the branch. + delete the branch `branch` irrespective of its merged status. `git checkout branch`:: make the current branch `branch`, updating the working - directory to reflect the version referenced by `branch` + directory to reflect the version referenced by `branch`. `git checkout -b new start-point`:: create a new branch `new` referencing `start-point`, and check it out. -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] Remove irrelevant reference from Tying it all together
Sorry Jon, but this might not be of any help to new Git users ;) Acked-by: Jon Loeliger j...@jdl.com Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 56bd088..9149846 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3924,8 +3924,7 @@ save the note about that state, in practice we tend to just write the result to the file pointed at by `.git/HEAD`, so that we can always see what the last committed state was. -Here is an ASCII art by Jon Loeliger that illustrates how -various pieces fit together. +Here is a picture that illustrates how various pieces fit together: -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] git prune is safe
git prune is safe in case of concurrent accesses to a repository but using it in such a case is not recommended. Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 9149846..ea843e6 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3299,17 +3299,11 @@ state, you can just prune all unreachable objects: $ git prune -and they'll be gone. But you should only run `git prune` on a quiescent +and they'll be gone. (You should only run `git prune` on a quiescent repository--it's kind of like doing a filesystem fsck recovery: you don't want to do that while the filesystem is mounted. - -(The same is true of `git fsck` itself, btw, but since -`git fsck` never actually *changes* the repository, it just reports -on what it found, `git fsck` itself is never 'dangerous' to run. -Running it while somebody is actually changing the repository can cause -confusing and scary messages, but it won't actually do anything bad. In -contrast, running `git prune` while somebody is actively changing the -repository is a *BAD* idea). +`git prune` is designed not to cause any harm in such cases of concurrent +accesses to a repository but you might receive confusing or scary messages.) [[recovering-from-repository-corruption]] Recovering from repository corruption -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] Improve section Merging multiple trees
Remove unnecessary quoting. Simplify description of three-way merge. Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index c20e8df..a7ca3e3 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -4004,27 +4004,26 @@ to see what the top commit was. Merging multiple trees -- -Git helps you do a three-way merge, which you can expand to n-way by -repeating the merge procedure arbitrary times until you finally -commit the state. The normal situation is that you'd only do one -three-way merge (two parents), and commit it, but if you like to, you -can do multiple parents in one go. +Git can help you perform a three-way merge, which can in turn be +used for a many-way merge by repeating the merge procedure several +times. The usual situation is that you only do one three-way merge +(reconciling two lines of history) and commit the result, but if +you like to, you can merge several branches in one go. -To do a three-way merge, you need the two sets of commit objects -that you want to merge, use those to find the closest common parent (a -third commit object), and then use those commit objects to find the -state of the directory (tree object) at these points. +To perform a three-way merge, you start with the two commits you +want to merge, find their closest common parent (a third commit), +and compare the trees corresponding to these three commits. -To get the base for the merge, you first look up the common parent -of two commits with +To get the base for the merge, look up the common parent of two +commits: - $ git merge-base commit1 commit2 - -which will return you the commit they are both based on. You should -now look up the tree objects of those commits, which you can easily -do with (for example) +This prints the name of a commit they are both based on. You should +now look up the tree objects of those commits, which you can easily +do with - $ git cat-file commit commitname | head -1 -- 1.8.3.msysgit.0 --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Document pack v4 format
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
For my education but may help people who are interested in the
format. Most is gathered from commit messages, except the delta tree
entries.
Thanks.
diff --git a/Documentation/technical/pack-format-v4.txt
b/Documentation/technical/pack-format-v4.txt
In the final version it may be a good idea to either have this
together with the documentation for the existing pack-formats, or
add a reference from the documentation for the existing formats to
point at this new file saying for v4 see
new file mode 100644
index 000..9123a53
--- /dev/null
+++ b/Documentation/technical/pack-format-v4.txt
@@ -0,0 +1,110 @@
+Git pack v4 format
+==
+
+== pack-*.pack files have the following format:
+
+ - A header appears at the beginning and consists of the following:
+
+ 4-byte signature:
+ The signature is: {'P', 'A', 'C', 'K'}
+
+ 4-byte version number (network byte order): must be version
+ number 4
+
+ 4-byte number of objects contained in the pack (network byte
+ order)
+
+ - (20 * nr_objects)-byte SHA-1 table: sorted in memcmp() order.
+
+ - Commit name dictionary: the uncompressed length in variable
+ encoding, followed by zlib-compressed dictionary. Each entry
+ consists of two prefix bytes storing timezone followed by a
+ NUL-terminated string.
The log and code use different names to call this thing. commit
name is misleading (e.g. it is not commit object name, but names
recorded in commit objects; it is not only for committer names,
but also applies to authors; it is not just names but also emails
and TZ used). Perhaps a better name would be ident table, as we
use the word ident only to refer to data to refer to people who
are recorded on either author/committer/tagger lines of the objects?
+ (undeltified representation)
+ n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+ [uncompressed data]
+ [compressed data]
These two lines are not useful; it is better spelled as [data
specific to object type] as you have to enumerate what are stored
and how for each type separately anyway.
+=== Tree representation
+
+ - n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+
+ - Number of trees in variable length encoding
+
+ - A number of trees, each consists of
The above number of trees sounds both wrong; aren't they the
number of tree entries (that can be blobs or subtrees) this tree
object records?
+Path component reference: an index, in variable length encoding,
+into tree path dictionary, which also covers entry mode.
+
+SHA-1 in SHA-1 reference encoding.
+
+Path component reference zero is an indicator of deltified portion and
+has the following format:
+
+ - path component reference: zero
+
+ - index of the entry to copy from, in variable length encoding
+
+ - number of entries in variable length encoding
+
+ - base tree in SHA-1 reference encoding
+
+=== SHA-1 reference encoding
+
+This encoding is used to encode SHA-1 efficiently if it's already in
+the SHA-1 table. It starts with an index number in variable length
+encoding. If it's not zero, its value minus one is the index in the
+SHA-1 table. If it's zero, 20 bytes of SHA-1 is followed.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/23] pack v4: object data copy
On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: Blob and tag objects have no particular changes except for their object header. Delta objects are also copied as is, except for their delta base reference which is converted to the new way as used elsewhere in pack v4 encoding i.e. an index into the SHA1 table or a literal SHA1 prefixed by 0 if not found in the table (see add_sha1_ref). This is true for both REF_DELTA as well as OFS_DELTA. Object payload is validated against the recorded CRC32 in the source pack index file when possible. Signed-off-by: Nicolas Pitre n...@fluxnic.net --- The title somewhat confused me until I realized that this series is building a program that would convert existing data from a single pack into packv4 format, not a pack-objects --pack-verison=4. I initially started with extensions to pack-objects but that quickly became a big hassle to keep things working while experimenting. So this tool is just a straight pack converter which in itself turned out to be quite complex already. Eventually its code could be merged into pack-objects. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Document pack v4 format
On Tue, 27 Aug 2013, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
For my education but may help people who are interested in the
format. Most is gathered from commit messages, except the delta tree
entries.
Excellent! That's the kind of thing I need help with.
Some corrections below.
Documentation/technical/pack-format-v4.txt (new) | 110
+++
1 file changed, 110 insertions(+)
create mode 100644 Documentation/technical/pack-format-v4.txt
diff --git a/Documentation/technical/pack-format-v4.txt
b/Documentation/technical/pack-format-v4.txt
new file mode 100644
index 000..9123a53
--- /dev/null
+++ b/Documentation/technical/pack-format-v4.txt
@@ -0,0 +1,110 @@
+Git pack v4 format
+==
+
+== pack-*.pack files have the following format:
+
+ - A header appears at the beginning and consists of the following:
+
+ 4-byte signature:
+ The signature is: {'P', 'A', 'C', 'K'}
+
+ 4-byte version number (network byte order): must be version
+ number 4
+
+ 4-byte number of objects contained in the pack (network byte
+ order)
Conceptually, I'd suggest we don't talk about what follows as part of
the header. Maybe the tables section would make more sense.
+ - (20 * nr_objects)-byte SHA-1 table: sorted in memcmp() order.
+
+ - Commit name dictionary: the uncompressed length in variable
+ encoding, followed by zlib-compressed dictionary. Each entry
+ consists of two prefix bytes storing timezone followed by a
+ NUL-terminated string.
+
+ Entries should be sorted by frequency so that the most frequent
+ entry has the smallest index, thus most efficient variable
+ encoding.
+
+ - Tree path dictionary: similar format to commit name
+ dictionary. Each entry consists of two prefix bytes storing entry
+ mode, then a NUL-terminated path name. Same sort order
+ recommendation applies.
+
+ - The header is followed by number of object entries, each of
+ which looks like this:
+
+ (undeltified representation)
+ n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+ [uncompressed data]
+ [compressed data]
+
+ (deltified representation)
+ n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+ base object name in SHA-1 reference encoding
+ compressed delta data
+
+ In undeltified format, blobs and tags do not have the
+ uncompressed data, all object content is compressed. Trees are
+ not compressed at all. Some headers in commits are stored
+ uncompressed, the rest is compressed.
+
+ All objects except trees are deltified and compressed the same
+ way in v3. Trees however are deltified differently and use
Let's note that commits are not deltified at all.
+ undeltified representation. See Tree representation below for
+ details.
+
+ - The trailer records 20-byte SHA-1 checksum of all of the above.
+
+=== Commit representation
+
+ - n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+
+ - Tree SHA-1 in SHA-1 reference encoding
+
+ - Parent count in variable length encoding
+
+ - Parent SHA-1s in SHA-1 reference encoding
+
+ - Author reference: the index, in variable length encoding, to comit
+name dictionary, which covers the name and also the time zone.
+
+ - Author timestamp in variable length encoding
+
+ - Committer reference: the index, in variable length encoding, to
+comit name dictionary, which covers the name and also the time
+zone.
+
+ - Committer timestamp in variable length encoding
+
+ - Compressed data of remaining header and the body
+
+=== Tree representation
+
+ - n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+
+ - Number of trees in variable length encoding
Maybe that would be better to refer to tree entries instead of trees.
+ - A number of trees, each consists of
+
+Path component reference: an index, in variable length encoding,
+into tree path dictionary, which also covers entry mode.
Note the index nust have 1 added due to 0 being reserved.
+SHA-1 in SHA-1 reference encoding.
+
+Path component reference zero is an indicator of deltified portion and
+has the following format:
+
+ - path component reference: zero
+
+ - index of the entry to copy from, in variable length encoding
I'd say index of the starting entry in the tree object to copy from to
be clearer. Also bit 0 of this index has a special meaning, therefore
the actual index must be shifted left by 1 bit.
+ - number of entries in variable length encoding
number of entries to copy ...
+
+ - base tree in SHA-1 reference encoding
The presence of this one depends on bit 0 in the index above. If that
bit is set then this base tree is provided. Otherwise it is not
provided and the previous base tree reference encountered in this tree
Re: [PATCH 05/11] Fix some typos and improve wording
Thomas Ackermann th.ac...@arcor.de writes: Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 6241a43..465d9cb 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -219,7 +219,7 @@ of development leading to that point. The best way to see how this works is using the linkgit:gitk[1] command; running gitk now on a Git repository and looking for merge -commits will help understand how the Git organizes history. +commits will help understand how Git organizes history. In the following, we say that commit X is reachable from commit Y if commit X is an ancestor of commit Y. Equivalently, you could say @@ -793,7 +793,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b - Or you could recall that the `...` operator selects all commits -contained reachable from either one reference or the other but not +reachable from either one reference or the other but not both; so - @@ -820,7 +820,7 @@ You could just visually inspect the commits since e05db0fd: $ gitk e05db0fd.. - -Or you can use linkgit:git-name-rev[1], which will give the commit a +or you can use linkgit:git-name-rev[1], which will give the commit a I think I agree with Jonathan that this reads better with Or, not or. Other than that looks good to me. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] Simplify How to make a commit
Sounds good. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] Call it Git User Manual and remove reference to very old Git version
Thomas Ackermann th.ac...@arcor.de writes: Reviewed-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- I tend to agree with Jonathan that this should be User's Manual. I've tentatively queued uncontroversial bits from v1 series already on 'pu', by the way, and I do not think I have time to queue rerolls of any topic today, so please expect a longer turn-around time than usual. Documentation/user-manual.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index fe723e4..103ec9a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1,6 +1,5 @@ -Git User's Manual (for version 1.5.3 or newer) -__ - +Git User Manual +___ Git is a fast distributed revision control system. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] Use git merge instead of git pull .
Thomas Ackermann th.ac...@arcor.de writes: git pull . works, but git merge is the recommended way for new users to do things. (The old description also should have read The former is actually *not* very commonly used.) It does not matter that you are unaware other people use it often. I'd suggest dropping the first hunk altogether. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/11] Improve section Manipulating branches
Thomas Ackermann th.ac...@arcor.de writes: `git branch -d branch`:: - delete the branch `branch`; if the branch you are deleting - points to a commit which is not reachable from the current - branch, this command will fail with a warning. + delete the branch `branch`; if the branch is not fully + merged in its upstream branch or contained in the current branch, + this command will fail with a warning. This is not a new problem, but it fails with an error, not a warning (which often is a message to caution but operation gets carried out anyway). For that matter, it might be better to say stops, as it is not a failure but is saving the user from losing information (in other words, that is a different kind of success ;-). It also stops you from deleting the branch you are currently on. I wonder if we want to mention that, too? `git branch -D branch`:: - even if the branch points to a commit not reachable - from the current branch, you may know that that commit - is still reachable from some other branch or tag. In that - case it is safe to use this command to force Git to delete - the branch. + delete the branch `branch` irrespective of its merged status. `git checkout branch`:: make the current branch `branch`, updating the working - directory to reflect the version referenced by `branch` + directory to reflect the version referenced by `branch`. `git checkout -b new start-point`:: create a new branch `new` referencing `start-point`, and check it out. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve font rendering on retina macbooks
Mads Dørup m...@dorup.dk writes: Hi there I've created a very small change to git gui that considerably improves the experience on my machine at least: diff --git a/git-gui/macosx/Info.plist b/git-gui/macosx/Info.plist index b3bf15f..1ade121 100644 --- a/git-gui/macosx/Info.plist +++ b/git-gui/macosx/Info.plist @@ -24,5 +24,7 @@ stringGITg/string keyCFBundleVersion/key string@@GITGUI_VERSION@@/string + keyNSHighResolutionCapable/key + true/ /dict /plist I've read the documentation for submitting patches to git where it says that I have to e-mail the patch to the mail list, with relevant developers as CC. Pat are you the relevant developer for this? Here is a screenshot comparison of before and after the change: https://github.com/git/git/pull/48 Please let me know how to proceed to get this patch in, if you like it. I've never contributed here before, so please me know about any procedures I have missed. Regards, Mads Dørup Looks like it makes a big difference from those pictures. Patch applied. Thank you. -- Pat Thoytshttp://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Aug 2013, #06; Tue, 27)
What's cooking in git.git (Aug 2013, #06; Tue, 27)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Git 1.8.4 was tagged and released recently, and we will shortly go
into a new development cycle for the next one, likely to be 1.8.5.
In this issue of What's cooking report, I haven't started sifting
the topics, most of which are marked as will cook in next, into
separate bins to indicate what order they would graduate yet. After
doing so, the tip of 'next' will be rewound, hopefully tomorrow but
it may slip by a day or so.
I expect this cycle to conclude at around the end of October, and we
will have another release by the end of the year. The first release
in the coming year may be named Git 2.0 with the promised
compatibility breakages.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* js/xread-in-full (2013-08-20) 1 commit
(merged to 'next' on 2013-08-20 at 95baa13)
+ stream_to_pack: xread does not guarantee to read all requested bytes
Originally merged to 'next' on 2013-08-20
A call to xread() was used without a loop around to cope with short
read in the codepath to stream new contents to a pack.
Will cook in 'next'.
* sb/mailmap-freeing-NULL-is-ok (2013-08-20) 1 commit
(merged to 'next' on 2013-08-20 at 303b16c)
+ mailmap: remove redundant check for freeing memory
Originally merged to 'next' on 2013-08-20
Will cook in 'next'.
* tg/index-struct-sizes (2013-08-20) 1 commit
(merged to 'next' on 2013-08-22 at df6b8e2)
+ read-cache: use fixed width integer types
Originally merged to 'next' on 2013-08-22
The code that reads from a region that mmaps an on-disk index
assumed that int/short are always 32/16 bits.
Will cook in 'next'.
* bc/completion-for-bash-3.0 (2013-08-22) 3 commits
(merged to 'next' on 2013-08-22 at 46c5bb2)
+ contrib/git-prompt.sh: handle missing 'printf -v' more gracefully
+ t9902-completion.sh: old Bash still does not support array+=('') notation
+ git-completion.bash: use correct Bash/Zsh array length syntax
Originally merged to 'next' on 2013-08-22
Some people still use rather old versions of bash, which cannot
grok some constructs like 'printf -v varname' the prompt and
completion code started to use recently.
Will cook in 'next'.
* bc/submodule-status-ignored (2013-08-20) 2 commits
(merged to 'next' on 2013-08-22 at 3dfd2a3)
+ submodule: don't print status output with ignore=all
+ submodule: fix confusing variable name
Originally merged to 'next' on 2013-08-22
Will cook in 'next'.
* jk/config-int-range-check (2013-08-21) 2 commits
(merged to 'next' on 2013-08-22 at 465efb3)
+ teach git-config to output large integers
+ config: properly range-check integer values
Originally merged to 'next' on 2013-08-22
git config --int section.var 3g should somehow diagnose that the
number does not fit in int (on 32-bit platforms anyway) but it
did not.
Will cook in 'next'.
* jk/duplicate-objects-in-packs (2013-08-24) 6 commits
- default pack.indexDuplicates to false
- index-pack: optionally reject packs with duplicate objects
- test index-pack on packs with recoverable delta cycles
- add tests for indexing packs with delta cycles
- sha1-lookup: handle duplicate keys with GIT_USE_LOOKUP
- test-sha1: add a binary output mode
A packfile that stores the same object more than once is broken and
will be rejected.
Will merge to 'next'.
* mm/mediawiki-dumb-push-fix (2013-08-21) 2 commits
- git-remote-mediawiki: add test and check Makefile targets
- git-remote-mediawiki: reset private ref after non-dumb push
Waiting for a reroll.
* rt/rebase-p-no-merge-summary (2013-08-21) 1 commit
(merged to 'next' on 2013-08-22 at 5310599)
+ rebase --preserve-merges: ignore merge.log config
Originally merged to 'next' on 2013-08-22
git rebase -p internally used the merge machinery, but when
rebasing, there should not be a need for merge summary.
Will cook in 'next'.
* rv/send-email-cache-generated-mid (2013-08-21) 2 commits
- git-send-email: Cache generated message-ids, use them when prompting
- git-send-email: add optional 'choices' parameter to the ask sub
* sp/clip-read-write-to-8mb (2013-08-20) 2 commits
(merged to 'next' on 2013-08-22 at 254e75d)
+ Revert compat/clipped-write.c: large write(2) fails on Mac OS X/XNU
+ xread, xwrite: limit size of IO to 8MB
Originally merged to 'next' on 2013-08-22
Send a large request to read(2)/write(2) as a smaller but still
reasonably large chunks, which would improve the latency when the
operation needs to be killed and incidentally works around broken
64-bit systems that cannot take a 2GB write or read in one go.
Will cook
Re: [PATCH 08/11] Improve section Merging multiple trees
Thomas Ackermann th.ac...@arcor.de writes: Remove unnecessary quoting. Simplify description of three-way merge. Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- The update is good, but I wonder if this belongs to User's manual these days. Perhaps we should start thinking about ripping the how to use plumbing out of the end-user manual and moving them to the core-tutorial where this kind of thing is more suited for. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/11] Remove unnecessary historical note from Object storage format
Good. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] git prune is safe
Thomas Ackermann th.ac...@arcor.de writes: git prune is safe in case of concurrent accesses to a repository but using it in such a case is not recommended. Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/user-manual.txt | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 9149846..ea843e6 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3299,17 +3299,11 @@ state, you can just prune all unreachable objects: $ git prune -and they'll be gone. But you should only run `git prune` on a quiescent +and they'll be gone. (You should only run `git prune` on a quiescent repository--it's kind of like doing a filesystem fsck recovery: you don't want to do that while the filesystem is mounted. - -(The same is true of `git fsck` itself, btw, but since -`git fsck` never actually *changes* the repository, it just reports -on what it found, `git fsck` itself is never 'dangerous' to run. -Running it while somebody is actually changing the repository can cause -confusing and scary messages, but it won't actually do anything bad. In -contrast, running `git prune` while somebody is actively changing the -repository is a *BAD* idea). +`git prune` is designed not to cause any harm in such cases of concurrent +accesses to a repository but you might receive confusing or scary messages.) These new two lines are good, but did we lose the mention of fsck that will report what is not dangling as dangling and such when run concurrently with other operations? Is that intended? [[recovering-from-repository-corruption]] Recovering from repository corruption -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] core.precomposeunicode is true by default
On 2013-08-27 18.27, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: 2) When we access a repo from Windows/Linux using SAMBA, You mean s/repo/repository that resides on HFS+/? Sorry being unclear here, trying being clearer with an example: I have a /data/Docs on my linux box, which is handled by git I export /data/Docs via SAMBA, and use the Finder under Mac OS to have it mounted on my Mac OS X box: //tb@Linux/Docs on /Volumes/Docs (smbfs, nodev, nosuid, mounted by tb) readdir() will return decomposed. When the repo is created by nonMacOS, core.precomposeunicode is undefined. The precomposition is off, but should be on, precomposed_unicode = -1, but should be = 1 I do not think UTF-8-MAC is widely available; even if you flip the bit on, would it help much? In the above example /data/Docs/.git/config was created by Linux, so it does not have core.precomposeunicode set, neither false nor true. The Linux box does not have UTF-8-MAC under iconv, but will ignore core.precomposeunicode anyway (since the code is not compiled here) The Mac OS machine sees it under /Volumes/Docs/.git/config And here we want the precomposition, even if core.precomposeunicode is not present in the config. It almost makes me wonder if you want not a per-repository but a per-machine configuration, i.e. Whichever repository I am accessing, either on a local filesystem or shared over the network, readdir() on my box reports wrong paths, and I need correction. That, or if it hurts, don't do the remote mount then. No, we don't need to be that restrictive. We already have repository/user/system wide configuration files, allowing tweeks and this is a good thing. Re-Re-reading $gmane/188940: I am happy having the V2 patch from today being queued, thanks. As a next step I will have a look into the advice machine. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] Use git merge instead of git pull .
On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote: Thomas Ackermann th.ac...@arcor.de writes: git pull . works, but git merge is the recommended way for new users to do things. (The old description also should have read The former is actually *not* very commonly used.) It does not matter that you are unaware other people use it often. I'd suggest dropping the first hunk altogether. Eh, the claim The former is actually very commonly used. is confusing on its own (even though it used to be true) and elaborating wouldn't help much with education, so the first hunk makes sense to me. But maybe it should have been done in a separate patch. ;-) Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: add _cb suffix to callback functions
On Tue, Aug 27, 2013 at 10:54 AM, Junio C Hamano gits...@pobox.com wrote: Natanael Copa nc...@alpinelinux.org writes: Commit 4d8dd1494e9f3af2e9738edaca40ada096f7bf10 introduced a build regression on uClibc which defines fgetc as macro. To work around that we add a _cb suffix to the callback functions. Signed-off-by: Natanael Copa nc...@alpinelinux.org --- Thanks; I think Peff already fixed this yesterday. For reference: http://thread.gmane.org/gmane.comp.version-control.git/233021/focus=233036 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] replace: forbid replacing an object with one of a different type
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
There is no case where one object can be replaced with one of a
different type while keeping the history valid, because:
* Annotated tags contain the type of the tagged object.
* The tree/parent lines in commits must be a tree and commits, resp.
* The object types referred to by trees are specified in the 'mode'
field:
100644 and 100755blob
16 commit
04 tree
(these are the only valid modes)
* Blobs don't point at anything.
The doc will be updated in a later patch.
Acked-by: Philip Oakley philipoak...@iee.org
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/builtin/replace.c b/builtin/replace.c
index 59d3115..9a94769 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -85,6 +85,7 @@ static int replace_object(const char *object_ref, const char
*replace_ref,
int force)
{
unsigned char object[20], prev[20], repl[20];
+ enum object_type obj_type, repl_type;
char ref[PATH_MAX];
struct ref_lock *lock;
@@ -100,6 +101,15 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
if (check_refname_format(ref, 0))
die('%s' is not a valid ref name., ref);
+ obj_type = sha1_object_info(object, NULL);
+ repl_type = sha1_object_info(repl, NULL);
+ if (obj_type != repl_type)
+ die(Objects must be of the same type.\n
+ '%s' points to a replaced object of type '%s'\n
+ while '%s' points to a replacement object of type '%s'.,
+ object_ref, typename(obj_type),
+ replace_ref, typename(repl_type));
+
if (read_ref(ref, prev))
hashclr(prev);
else if (!force)
--
1.8.4.rc1.26.gdd51ee9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] t6050-replace: add test to clean up all the replace refs
Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- t/t6050-replace.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh index 5c352c4..05be228 100755 --- a/t/t6050-replace.sh +++ b/t/t6050-replace.sh @@ -276,4 +276,10 @@ test_expect_success 'replaced and replacement objects must be of the same type' grep $BLOB. points to a replacement object of type .blob err ' +test_expect_success 'replace ref cleanup' ' + test -n $(git replace) + git replace -d $(git replace) + test -z $(git replace) +' + test_done -- 1.8.4.rc1.26.gdd51ee9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] t6050-replace: test that objects are of the same type
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index decdc33..5c352c4 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -263,4 +263,17 @@ test_expect_success 'not just commits' '
test_cmp file.replaced file
'
+test_expect_success 'replaced and replacement objects must be of the same
type' '
+ test_must_fail git replace mytag $HASH1 2err
+ grep mytag. points to a replaced object of type .tag err
+ grep $HASH1. points to a replacement object of type .commit err
+ test_must_fail git replace HEAD^{tree} HEAD~1 2err
+ grep HEAD^{tree}. points to a replaced object of type .tree err
+ grep HEAD~1. points to a replacement object of type .commit err
+ BLOB=$(git rev-parse :file)
+ test_must_fail git replace HEAD^ $BLOB 2err
+ grep HEAD^. points to a replaced object of type .commit err
+ grep $BLOB. points to a replacement object of type .blob err
+'
+
test_done
--
1.8.4.rc1.26.gdd51ee9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] Documentation/replace: add Creating Replacement Objects section
There were no hints in the documentation about how to create replacement objects. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index aa66d27..736b48c 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -64,6 +64,19 @@ OPTIONS Typing git replace without arguments, also lists all replace refs. +CREATING REPLACEMENT OBJECTS + + +linkgit:git-filter-branch[1], linkgit:git-hash-object[1] and +linkgit:git-rebase[1], among other git commands, can be used to create +replacement objects from existing objects. + +If you want to replace many blobs, trees or commits that are part of a +string of commits, you may just want to create a replacement string of +commits and then only replace the commit at the tip of the target +string of commits with the commit at the tip of the replacement string +of commits. + BUGS Comparing blobs or trees that have been replaced with those that @@ -76,6 +89,9 @@ pending objects. SEE ALSO +linkgit:git-hash-object[1] +linkgit:git-filter-branch[1] +linkgit:git-rebase[1] linkgit:git-tag[1] linkgit:git-branch[1] linkgit:git[1] -- 1.8.4.rc1.26.gdd51ee9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] Documentation/replace: state that objects must be of the same type
A previous patch ensures that both the replaced and the replacement objects passed to git replace must be of the same type. While at it state that there is no other restriction on both objects. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index e0b4057..aa66d27 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -20,6 +20,9 @@ The name of the 'replace' reference is the SHA-1 of the object that is replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. +The replaced object and the replacement object must be of the same type. +There is no other restriction on them. + Unless `-f` is given, the 'replace' reference must not yet exist. Replacement references will be used by default by all Git commands @@ -69,9 +72,7 @@ go back to a replaced commit will move the branch to the replacement commit instead of the replaced commit. There may be other problems when using 'git rev-list' related to -pending objects. And of course things may break if an object of one -type is replaced by an object of another type (for example a blob -replaced by a commit). +pending objects. SEE ALSO -- 1.8.4.rc1.26.gdd51ee9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Check replacement object type and minor updates
The only changes compared to the previous version are those suggested by Johannes: - the error message is now: Objects must be of the same type.\n '%s' points to a replaced object of type '%s'\n while '%s' points to a replacement object of type '%s'. - the test uses . instead of '\'' Only patchs 1/5 and 3/5 were changed. Christian Couder (5): replace: forbid replacing an object with one of a different type Documentation/replace: state that objects must be of the same type t6050-replace: test that objects are of the same type t6050-replace: add test to clean up all the replace refs Documentation/replace: add Creating Replacement Objects section Documentation/git-replace.txt | 23 --- builtin/replace.c | 10 ++ t/t6050-replace.sh| 19 +++ 3 files changed, 49 insertions(+), 3 deletions(-) -- 1.8.4.rc1.26.gdd51ee9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/23] pack v4: commit object encoding
On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: + /* parse the tree line */ + if (in + 46 = tail || memcmp(in, tree , 5) || in[45] != '\n') + goto bad_data; + if (get_sha1_hex(in + 5, sha1) 0) + goto bad_data; Is this strict enough to guarantee roundtrip hash identity? Because get_sha1_hex() accepts hexadecimal represented with uppercase A-F, you need to reject such a broken commit object, no? BTW, is there any such objects in existence where sha1 ascii strings are represented using uppercase letters? Because there would be a simple way to encode that fact in the pack v4 sha1 reference... but that change has to happen now. I'm already claiming we won't support mixed case though. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/credential/netrc/git-credential-netrc: Use of uninitialized value in string
On Mon, Aug 26, 2013 at 08:56:23PM -0700, Junio C Hamano wrote: Antoine Pelisse apeli...@gmail.com writes: I've tried to use the netrc credential with git-send-email (v1.8.4-rc2), and I've had the following log (running with -d -v): Peff what do you think? From credential layer's point of view, I think we make it totally up to the helper to decide if a request matches what it supports, and if a particular helper wants to make sure it is asked for a specific protocol, that is an OK thing to do, but it feels unnecessarily unfriendly and treating missing proto specification as a wildcard to talk to the specified host over any protocol may not hurt, I would think. Right. It is up to the credential helper to map git's request into whatever storage it has. So I think the right answer is whatever is normal and expected for netrc. Unfortunately that is not really a standardized format. The original netrc was ftp-only, and did not have a port or protocol field at all. Programs like curl extend it automatically to http, and just googling around seems to show other programs using it for imap and smtp. So I think there is some precedence in simply treating a missing port field as match any port/protocol on the machine. The upside is that it is convenient for the user. The downside is that we might accidentally send a password to a service that the user does not expect, which could compromise security. It would at least be on the matching host, but the protocol might not be as secure as the one the user intended (e.g., smtp without starttls, when the password was meant to only go over imap-over-ssl). So I'm on the fence. It is very unlikely to be a bad thing, but if it is, it may expose user passwords in cleartext. If we are going to keep the current behavior, it probably needs to be documented, and certainly: Use of uninitialized value $_[2] in printf at /home/antoine/code/git/contrib/credential/netrc/git-credential-netrc line 419. compare protocol [] to [smtp] (entry: password=secret, username=apeli...@gmail.com, host=smtp.gmail.com:587) Use of uninitialized value in string eq at /home/antoine/code/git/contrib/credential/netrc/git-credential-netrc line 378. ...these should more cleanly handle the missing field. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/23] pack v4: commit object encoding
Nicolas Pitre n...@fluxnic.net writes: On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: + /* parse the tree line */ + if (in + 46 = tail || memcmp(in, tree , 5) || in[45] != '\n') + goto bad_data; + if (get_sha1_hex(in + 5, sha1) 0) + goto bad_data; Is this strict enough to guarantee roundtrip hash identity? Because get_sha1_hex() accepts hexadecimal represented with uppercase A-F, you need to reject such a broken commit object, no? BTW, is there any such objects in existence where sha1 ascii strings are represented using uppercase letters? Any commit or tag object that refers to another object with SHA-1 using uppercase letters is broken and invalid. get_sha1_hex() is not limited to reading these (i.e. it also is used to read object name given on the command line) so it is lenient, but the above codepath should care so that the result of hashing will stay the same. Because there would be a simple way to encode that fact in the pack v4 sha1 reference... but that change has to happen now. Hence, I do not think we care. I'm already claiming we won't support mixed case though. Yeah, I am already claiming we won't support any uppercase ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] replace: forbid replacing an object with one of a different type
Christian Couder chrisc...@tuxfamily.org writes: Users replacing an object with one of a different type were not prevented to do so, even if it was obvious, and stated in the doc, that bad things would result from doing that. To avoid mistakes, it is better to just forbid that though. There is no case where one object can be replaced with one of a different type while keeping the history valid, because: * Annotated tags contain the type of the tagged object. If you replace the tagged object and the tag at the same time, wouldn't that make the resulting history valid again? Granted, there may not be a strong reason to reuse the object name of the tagged object in such a case, but this there may not be is merely I do not think of offhand, so I am not sure what workflow of other people we are breaking with this change. A light-weight tag may already point at the tagged object (in other words, the object name of the tagged object is known to the outside world) and that could be a reason why you would need to reuse the object name of that object while changing its type. I dunno. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] write_index: optionally allow broken null sha1s
On Mon, Aug 26, 2013 at 05:20:53PM -0400, Jeff King wrote:
And by your rule above, the advice would be each of these tests
should say setup in the description. That makes sense to me, and I
don't mind doing it here.
[...]
I totally missed your original point, then. I don't mind combining the
last two into a single test. That makes sense to me (I only split them
at all because I added the second one much later during the
development).
So here is a re-roll with:
1. The commit message tweaks you suggested
2. Annotating the setup tests by using the word setup
3. Combining the final two tests to filter and check the result.
I also added your Reviewed-by, since you gave it for the previous
version, and all of the changes are taking your suggestions. :)
-- 8 --
Subject: write_index: optionally allow broken null sha1s
Commit 4337b58 (do not write null sha1s to on-disk index,
2012-07-28) added a safety check preventing git from writing
null sha1s into the index. The intent was to catch errors in
other parts of the code that might let such an entry slip
into the index (or worse, a tree).
Some existing repositories may have invalid trees that
contain null sha1s already, though. Until 4337b58, a common
way to clean this up would be to use git-filter-branch's
index-filter to repair such broken entries. That now fails
when filter-branch tries to write out the index.
Introduce a GIT_ALLOW_NULL_SHA1 environment variable to
relax this check and make it easier to recover from such a
history.
It is tempting to not involve filter-branch in this commit
at all, and instead require the user to manually invoke
GIT_ALLOW_NULL_SHA1=1 git filter-branch ...
to perform an index-filter on a history with trees with null
sha1s. That would be slightly safer, but requires some
specialized knowledge from the user. So let's set the
GIT_ALLOW_NULL_SHA1 variable automatically when checking out
the to-be-filtered trees. Advice on using filter-branch to
remove such entries already exists on places like
stackoverflow, and this patch makes it Just Work again on
recent versions of git.
Further commands that touch the index will still notice and
fail, unless they actually remove the broken entries. A
filter-branch whose filters do not touch the index at all
will not error out (since we complain of the null sha1 only
on writing, not when making a tree out of the index), but
this is acceptable, as we still print a loud warning, so the
problem is unlikely to go unnoticed.
Signed-off-by: Jeff King p...@peff.net
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
git-filter-branch.sh | 5 ++--
read-cache.c | 13 --
t/t7009-filter-branch-null-sha1.sh | 49 ++
3 files changed, 63 insertions(+), 4 deletions(-)
create mode 100755 t/t7009-filter-branch-null-sha1.sh
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ac2a005..98e8fe4 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -283,11 +283,12 @@ while read commit parents; do
case $filter_subdir in
)
- git read-tree -i -m $commit
+ GIT_ALLOW_NULL_SHA1=1 git read-tree -i -m $commit
;;
*)
# The commit may not have the subdirectory at all
- err=$(git read-tree -i -m $commit:$filter_subdir 21) || {
+ err=$(GIT_ALLOW_NULL_SHA1=1 \
+ git read-tree -i -m $commit:$filter_subdir 21) || {
if ! git rev-parse -q --verify $commit:$filter_subdir
then
rm -f $GIT_INDEX_FILE
diff --git a/read-cache.c b/read-cache.c
index c3d5e35..83a7414 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1817,8 +1817,17 @@ int write_index(struct index_state *istate, int newfd)
continue;
if (!ce_uptodate(ce) is_racy_timestamp(istate, ce))
ce_smudge_racily_clean_entry(ce);
- if (is_null_sha1(ce-sha1))
- return error(cache entry has null sha1: %s, ce-name);
+ if (is_null_sha1(ce-sha1)) {
+ static const char msg[] = cache entry has null sha1:
%s;
+ static int allow = -1;
+
+ if (allow 0)
+ allow = git_env_bool(GIT_ALLOW_NULL_SHA1, 0);
+ if (allow)
+ warning(msg, ce-name);
+ else
+ return error(msg, ce-name);
+ }
if (ce_write_entry(c, newfd, ce, previous_name) 0)
return -1;
}
diff --git a/t/t7009-filter-branch-null-sha1.sh
b/t/t7009-filter-branch-null-sha1.sh
new file mode 100755
index 000..a997f7a
--- /dev/null
+++ b/t/t7009-filter-branch-null-sha1.sh
@@ -0,0 +1,49 @@
+#!/bin/sh
+
Re: [PATCH 04/11] Use git merge instead of git pull .
Jonathan Nieder jrnie...@gmail.com writes: On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote: Thomas Ackermann th.ac...@arcor.de writes: git pull . works, but git merge is the recommended way for new users to do things. (The old description also should have read The former is actually *not* very commonly used.) It does not matter that you are unaware other people use it often. I'd suggest dropping the first hunk altogether. Eh, the claim The former is actually very commonly used. is confusing on its own (even though it used to be true) and elaborating wouldn't help much with education, so the first hunk makes sense to me. But maybe it should have been done in a separate patch. ;-) Yeah, it may make sense to replace it with something like ... and if you think about the fact that your local repository is not at all special, it makes sense that you can pull from it just like you pull from other places, without mentioning how common it is. I do agree that it is a separate topic. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: * jk/config-int-range-check (2013-08-21) 2 commits (merged to 'next' on 2013-08-22 at 465efb3) + teach git-config to output large integers + config: properly range-check integer values Originally merged to 'next' on 2013-08-22 git config --int section.var 3g should somehow diagnose that the number does not fit in int (on 32-bit platforms anyway) but it did not. Will cook in 'next'. I think Jonathan had some concerns about the test in the first one, and there was an open question in the second of whether we wanted to add something like --ulong, call it something more agnostic like --file-size, or simply teach --int to use 64-bit integers everywhere for simplicity. Thoughts? * jk/mailmap-incomplete-line (2013-08-25) 2 commits - mailmap: avoid allocation when reading from blob - mailmap: handle mailmap blobs without trailing newlines Will merge to 'next'. Did you want me to squash these? The second one more or less eradicates the changes made to the first one. I mainly did them separately in case we were going to only do the first half on maint. * jk/write-broken-index-with-nul-sha1 (2013-08-26) 1 commit - write_index: optionally allow broken null sha1s Am I waiting for another reroll? Yep, just sent v3. [Stalled] [...] * jk/list-objects-sans-blobs (2013-06-06) 4 commits . archive: ignore blob objects when checking reachability . list-objects: optimize revs-blob_objects = 0 case . upload-archive: restrict remote objects with reachability check . clear parsed flag when we free tree buffers Attempt to allow archive --remote=$there $arbitrary_sha1 while keeping the reachability safety. Seems to break some tests in a trivial and obvious way. You can probably discard this one (though you may want to take the bottom as a separate cleanup). I think we decided that the right strategy is to do the : split as we do now, but then do the normal commit-level reachability check on the left-hand side. I just haven't gotten around to writing the code yet. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
Jeff King p...@peff.net writes: On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: * jk/config-int-range-check (2013-08-21) 2 commits (merged to 'next' on 2013-08-22 at 465efb3) + teach git-config to output large integers + config: properly range-check integer values Originally merged to 'next' on 2013-08-22 git config --int section.var 3g should somehow diagnose that the number does not fit in int (on 32-bit platforms anyway) but it did not. Will cook in 'next'. I think Jonathan had some concerns about the test in the first one, and there was an open question in the second of whether we wanted to add something like --ulong, call it something more agnostic like --file-size, or simply teach --int to use 64-bit integers everywhere for simplicity. Thoughts? Are the scripts that use git config --type expected to know the representation type used by C binaries on the platform? If so, letting them say git config --ulong 3g when setting a new value, and git config --ulong when asking the current value with range checking does make sense. When the underlying code uses int (as opposed to int32_t) to read the value for a variable on any platform, then git config --int 3g that does not warn only because it is running on 64-bit platform may not help very much. The users can protect themselves by learning to use config --int32 3g, but I am not sure that is a sensible approach---rather, config --int that makes sure that the current value or the value being set is within range on any sensible platform may be a lot more user-friendly. * jk/mailmap-incomplete-line (2013-08-25) 2 commits - mailmap: avoid allocation when reading from blob - mailmap: handle mailmap blobs without trailing newlines Will merge to 'next'. Did you want me to squash these? The second one more or less eradicates the changes made to the first one. I mainly did them separately in case we were going to only do the first half on maint. Hmm, perhaps. Is reading mailmap from a blob commonly done and deserves a maint update down for 1.8.3/1.8.2 series? I'll be rewinding the 'next' soonish (either tomorrow or Thursday), so I'll try to remember not to merge this (yet). * jk/write-broken-index-with-nul-sha1 (2013-08-26) 1 commit - write_index: optionally allow broken null sha1s Am I waiting for another reroll? Yep, just sent v3. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] Call it Git User Manual and remove reference to very old Git version
Junio C Hamano gits...@pobox.com writes: | Thomas Ackermann th.ac...@arcor.de writes: Reviewed-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- | I tend to agree with Jonathan that this should be User's Manual. Not going into which one might be more correct, but a quick google search for User's Manual and User Manual give these results: User's Manual: 5.7M hits. User Manual: ~29M hits. -- Lgb -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano gits...@pobox.com wrote: * jh/remote-hg-fetch-fix (2013-07-25) 2 commits (merged to 'next' on 2013-07-25 at 33161ad) + Revert remotes-hg: bugfix for fetching non local remotes (merged to 'next' on 2013-07-24 at 9c96641) + remotes-hg: bugfix for fetching non local remotes Originally merged to 'next' on 2013-07-25 Reverted. Waiting for the final patch to replace, after discussion settles. I think it has already been replaced by: * fc/remote-hg-shared-setup (2013-08-11) 2 commits (merged to 'next' on 2013-08-14 at aae6858) + remote-hg: add shared repo upgrade + remote-hg: ensure shared repo is initialized Originally merged to 'next' on 2013-08-14 Will cook in 'next'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/23] pack v4: commit object encoding
On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: On Tue, 27 Aug 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: +/* parse the tree line */ +if (in + 46 = tail || memcmp(in, tree , 5) || in[45] != '\n') +goto bad_data; +if (get_sha1_hex(in + 5, sha1) 0) +goto bad_data; Is this strict enough to guarantee roundtrip hash identity? Because get_sha1_hex() accepts hexadecimal represented with uppercase A-F, you need to reject such a broken commit object, no? BTW, is there any such objects in existence where sha1 ascii strings are represented using uppercase letters? Any commit or tag object that refers to another object with SHA-1 using uppercase letters is broken and invalid. get_sha1_hex() is not limited to reading these (i.e. it also is used to read object name given on the command line) so it is lenient, but the above codepath should care so that the result of hashing will stay the same. Indeed, hence my concern about encoding the original case. Because there would be a simple way to encode that fact in the pack v4 sha1 reference... but that change has to happen now. Hence, I do not think we care. I'm already claiming we won't support mixed case though. Yeah, I am already claiming we won't support any uppercase ;-). Perfect! I've added a get_sha1_lowhex() to my tree. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
[+cc Jonathan] On Tue, Aug 27, 2013 at 02:05:01PM -0700, Junio C Hamano wrote: * jk/config-int-range-check (2013-08-21) 2 commits [...] I think Jonathan had some concerns about the test in the first one, and there was an open question in the second of whether we wanted to add something like --ulong, call it something more agnostic like --file-size, or simply teach --int to use 64-bit integers everywhere for simplicity. Are the scripts that use git config --type expected to know the representation type used by C binaries on the platform? I think that's an open question. My argument was that you would want to be able to get the same range errors that git would see internally. So I know that if git config --ulong pack.packSizeLimit 10g does not fail, then pack-objects itself will be fine when reading the value. So if you buy the argument that such a thing is useful, then: 1. We would want to keep the range checks we have for --int. 2. We would need new types to represent items beyond --int, and they should match what git will do internally. You can call it --ulong, or --uint64, or --file-size, or whatever you like, but --int does not cut it. The counterarguments I can see are: 1. Who cares? If you want to know whether pack-objects will choke on your huge config value, then run pack-objects. 2. Such a check would involve knowing which type we use internally to look at packSizeLimit, and that is utterly undocumented (and subject to change; e.g., it seems kind of senseless that we have a 4G pack-size limit on 32-bit platforms, and we may want to fix that). So if you do not buy the argument that communicating git's internal range checks is useful, then we can simply say --int is magically long on every platform, and you can use it for everything numeric. And implement it with int64_t. You may be able to read or write some values for certain keys that git will barf on internally, but that is git's problem. The one thing it doesn't get you is that you can currently set unsigned values to -1 in the config to have them treated as ULONG_MAX. This is undocumented and as far as I know not used by anyone. But it would be one place where the interpretation of git config key is not the same as what git does internally, and you do not get a warning or death, but rather you just get a completely different value. I don't feel too strongly either way. I mostly kept the range checks for --int because that is how the code already worked, and I assumed that was what was desired. But given what I know of the history of the config code, it is probably a completely random side effect of how it is implemented. :) I can try to prepare a series going in that direction (we still need to fix the internal truncation that currently happens, though). * jk/mailmap-incomplete-line (2013-08-25) 2 commits - mailmap: avoid allocation when reading from blob - mailmap: handle mailmap blobs without trailing newlines Will merge to 'next'. Did you want me to squash these? The second one more or less eradicates the changes made to the first one. I mainly did them separately in case we were going to only do the first half on maint. Hmm, perhaps. Is reading mailmap from a blob commonly done and deserves a maint update down for 1.8.3/1.8.2 series? Yes. The tip of jk/mailmap-from-blob turned on blob reading by default in bare repositories. So if you have a .mailmap without a terminating newline, git shortlog will segfault by default in a bare version of your repository. I do not know if it is so serious a fix that you need to go back to v1.8.2 series, but I think it is definitely maint-worthy. I was worried initially that the second part of the patch would involve too much refactoring for maint, but it actually turned out pretty simple. I'll prepare a squashed version that I think should be suitable for maint. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
Junio C Hamano gits...@pobox.com writes: What's cooking in git.git (Aug 2013, #06; Tue, 27) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Git 1.8.4 was tagged and released recently, and we will shortly go into a new development cycle for the next one, likely to be 1.8.5. In this issue of What's cooking report, I haven't started sifting the topics, most of which are marked as will cook in next, into separate bins to indicate what order they would graduate yet. After doing so, the tip of 'next' will be rewound, hopefully tomorrow but it may slip by a day or so. I am nominating the following topics to graduate to 'master' by the end of this week (or in the middle of the next week at the latest). Those graduating earlier than others are: (1) trivially correct and safe; (2) of minor impact and even if they are broken, no real harm will be done; or (3) touch parts of the system that are so important that we would want to learn unforseen breakages sooner rather than later in the cycle, and we have done sufficient reviews and testing on 'next' already. The last category is of particular importance, as we seemed to have seen a few regression reports _after_ topics that have been cooking for a long time in 'next' graduated to 'master' during the latest cycle. We need to recruit more people from minority platforms and with various different workflows to test 'next' more, but that will not happen overnight, so the next best thing we can do is to feed topics that are reasonably well cooked in 'next' early to 'master'. * nd/fetch-pack-shallow-fix (2013-08-25) 1 commit (merged to 'next' on 2013-08-27 at 7c2a162) + fetch-pack: do not remove .git/shallow file when --depth is not specified Recent short-cut clone connectivity check topic broke a shallow repository when a fetch operation tries to auto-follow tags. Will merge to 'master', aiming to later apply to 1.8.4.x maintenance track. * hv/config-from-blob (2013-08-26) 1 commit (merged to 'next' on 2013-08-27 at 7bc9019) + config: do not use C function names as struct members Portability fix. Will merge to 'master', aiming to later apply to 1.8.4.x maintenance track. * rj/doc-rev-parse (2013-07-22) 2 commits (merged to 'next' on 2013-07-22 at 8188667) + rev-parse(1): logically group options + rev-parse: remove restrictions on some options Will merge to 'master'. * mb/docs-favor-en-us (2013-08-01) 1 commit (merged to 'next' on 2013-08-06 at 763d868) + Provide some linguistic guidance for the documentation. Declare that the official grammar spelling of the source of this project is en_US, but strongly discourage patches only to fix existing en_UK strings to avoid unnecessary churns. Will merge to 'master'. * nd/sq-quote-buf (2013-07-30) 3 commits (merged to 'next' on 2013-08-01 at dc7934a) + quote: remove sq_quote_print() + tar-tree: remove dependency on sq_quote_print() + for-each-ref, quote: convert *_quote_print - *_quote_buf Code simplification as a preparatory step to something larger. Will merge to 'master'. * mm/no-shell-escape-in-die-message (2013-08-07) 1 commit (merged to 'next' on 2013-08-08 at bddff86) + die_with_status: use printf '%s\n', not echo Fixes a minor bug in git rebase -i (there could be others, as the root cause is pretty generic) where the code feeds a random, data dependeant string to 'echo' and expects it to come out literally. Will merge to 'master'. * sb/parseopt-boolean-removal (2013-08-07) 9 commits (merged to 'next' on 2013-08-08 at b138a2d) + revert: use the OPT_CMDMODE for parsing, reducing code + checkout-index: fix negations of even numbers of -n + config parsing options: allow one flag multiple times + hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP + branch, commit, name-rev: ease up boolean conditions + checkout: remove superfluous local variable + log, format-patch: parsing uses OPT__QUIET + Replace deprecated OPT_BOOLEAN by OPT_BOOL + Remove deprecated OPTION_BOOLEAN for parsing arguments (this branch uses jc/parseopt-command-modes.) Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary. Will merge to 'master'. * ap/remote-hg-tilde-is-home-directory (2013-08-09) 1 commit (merged to 'next' on 2013-08-14 at cd963e3) + remote-hg: fix path when cloning with tilde expansion Will merge to 'master'. * rt/doc-merge-file-diff3 (2013-08-09) 1 commit (merged to 'next' on 2013-08-14 at 1e5847b) + Documentation/git-merge-file: document option --diff3 Will merge to 'master'. * sb/misc-cleanup (2013-08-09) 3 commits (merged to 'next' on 2013-08-14 at 9e7ff9a) + rm: remove unneeded null pointer check
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
Jeff King p...@peff.net writes: I don't feel too strongly either way. I mostly kept the range checks for --int because that is how the code already worked, and I assumed that was what was desired. But given what I know of the history of the config code, it is probably a completely random side effect of how it is implemented. :) ;-) I can try to prepare a series going in that direction (we still need to fix the internal truncation that currently happens, though). Yeah, allowing range checks to allow those who do set using git config from the command line to protect themselves is in theory a good idea, but in practice that means they need to know the internal type (and they need to know to pass --int in the first place), so it may be a losing proposition. I do not know if it is so serious a fix that you need to go back to v1.8.2 series, but I think it is definitely maint-worthy. I was worried initially that the second part of the patch would involve too much refactoring for maint, but it actually turned out pretty simple. I'll prepare a squashed version that I think should be suitable for maint. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
Antoine Pelisse apeli...@gmail.com writes: On Tue, Aug 27, 2013 at 9:22 PM, Junio C Hamano gits...@pobox.com wrote: * jh/remote-hg-fetch-fix (2013-07-25) 2 commits (merged to 'next' on 2013-07-25 at 33161ad) + Revert remotes-hg: bugfix for fetching non local remotes (merged to 'next' on 2013-07-24 at 9c96641) + remotes-hg: bugfix for fetching non local remotes Originally merged to 'next' on 2013-07-25 Reverted. Waiting for the final patch to replace, after discussion settles. I think it has already been replaced by: Surely, of course. I think I just ignored the text altogether when I moved it to the discarded section. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)
On Tue, Aug 27, 2013 at 12:22:30PM -0700, Junio C Hamano wrote: * kk/tests-with-no-perl (2013-08-24) 4 commits - reset test: modernize style - t/t7106-reset-unborn-branch.sh: Add PERL prerequisite - add -i test: use skip_all instead of repeated PERL prerequisite - Make test using invalid commit with -C more strict Am I waiting for another reroll? From these four commits only the second and last one are from me and I'm happy with their form as in pu (I see that you have already introduced your improvement of commit --allow-empty to the last one). Unless there are some remarks to them. But I don't know what about Jonathan's commits. As a matter of fact I have no idea how I even should reroll the topic that includes commits with mixed authorship. -- Kacper -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
???????
Contact Me for a business Deal -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] documentation: clarify notes for clean.requireForce
Add -i (interactive clean option) to clarify the documentation for clean.requireForce config variable. Signed-off-by: Jiang Xin worldhello@gmail.com --- Documentation/config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8361380..7321a54 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -795,8 +795,8 @@ browser.tool.path:: working repository in gitweb (see linkgit:git-instaweb[1]). clean.requireForce:: - A boolean to make git-clean do nothing unless given -f - or -n. Defaults to true. + A boolean to make git-clean do nothing unless given -f, + -i or -n. Defaults to true. color.branch:: A boolean to enable/disable color in the output of -- 1.8.3.rc2.29.g07b4019 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] mailmap: handle mailmap blobs without trailing newlines
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only end - buf
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.
We could fix it with:
unsigned long linelen = end - buf + !!*end;
but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.
Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.
This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).
Signed-off-by: Jeff King p...@peff.net
---
This is the squashed version to replace what's in
jk/mailmap-incomplete-line.
mailmap.c | 21 +
t/t4203-mailmap.sh | 16 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index b16542f..caa7c6b 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -187,20 +187,17 @@ static void read_mailmap_buf(struct string_list *map,
return 0;
}
-static void read_mailmap_buf(struct string_list *map,
-const char *buf, unsigned long len,
-char **repo_abbrev)
+static void read_mailmap_string(struct string_list *map, char *buf,
+ char **repo_abbrev)
{
- while (len) {
- const char *end = strchrnul(buf, '\n');
- unsigned long linelen = end - buf + 1;
- char *line = xmemdupz(buf, linelen);
+ while (*buf) {
+ char *end = strchrnul(buf, '\n');
- read_mailmap_line(map, line, repo_abbrev);
+ if (*end)
+ *end++ = '\0';
- free(line);
- buf += linelen;
- len -= linelen;
+ read_mailmap_line(map, buf, repo_abbrev);
+ buf = end;
}
}
@@ -224,7 +221,7 @@ static int read_mailmap_blob(struct string_list *map,
if (type != OBJ_BLOB)
return error(mailmap is not a blob: %s, name);
- read_mailmap_buf(map, buf, size, repo_abbrev);
+ read_mailmap_string(map, buf, repo_abbrev);
free(buf);
return 0;
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index aae30d9..10c7b12 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -159,7 +159,8 @@ test_expect_success 'setup mailmap blob tests' '
Blob Guy aut...@example.com
Blob Guy b...@company.xx
EOF
- git add just-bugs both
+ printf Tricky Guy aut...@example.com no-newline
+ git add just-bugs both no-newline
git commit -m my mailmaps
echo Repo Guy aut...@example.com .mailmap
echo Internal Guy aut...@example.com internal.map
@@ -243,6 +244,19 @@ test_expect_success 'mailmap.blob defaults to
HEAD:.mailmap in bare repo' '
)
'
+test_expect_success 'mailmap.blob can handle blobs without trailing newline' '
+ cat expect -\EOF
+ Tricky Guy (1):
+ initial
+
+ nick1 (1):
+ second
+
+ EOF
+ git -c mailmap.blob=map:no-newline shortlog HEAD actual
+ test_cmp expect actual
+'
+
test_expect_success 'cleanup after mailmap.blob tests' '
rm -f .mailmap
'
--
1.8.4.2.g87d4a77
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] Preliminary pack v4 support
On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano gits...@pobox.com wrote: As you have 0-index escape hatch for SHA-1 table, but no similar escape hatch for the people's name table, I can see why it may be cumbersome to fix a thin pack by only appending to a received packfile and updating a few header fields, though. We also need an escape hatch for path name table. But what if we store appended objects in OBJ_REF_DELTA format where base ref is empty tree/commit and cached by sha1_file.c? We won't need to update dictionary tables. Parsing is a bit ugly though (e.g. v3 tree with v2 base) but we have to deal with that anyway because people can have v2 and v3 packs mixed in. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] Preliminary pack v4 support
On Wed, 28 Aug 2013, Duy Nguyen wrote: On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano gits...@pobox.com wrote: As you have 0-index escape hatch for SHA-1 table, but no similar escape hatch for the people's name table, I can see why it may be cumbersome to fix a thin pack by only appending to a received packfile and updating a few header fields, though. We also need an escape hatch for path name table. Well, right. I think this is probably the cleanest solution if we don't want to update the commit/tree dictionary table with new entries (they could simply be appended at the end). That wouldn't work for the SHA1 table though, so perhaps a secondary table for the appended objects could then be carried into the pack index file. But what if we store appended objects in OBJ_REF_DELTA format where base ref is empty tree/commit and cached by sha1_file.c? I don't follow you here. Missing objects need to be added to the pack, they can't be cached anywhere. We won't need to update dictionary tables. Parsing is a bit ugly though (e.g. v3 tree with v2 base) but we have to deal with that anyway because people can have v2 and v3 packs mixed in. Absolutely. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] Preliminary pack v4 support
On Wed, Aug 28, 2013 at 9:58 AM, Nicolas Pitre n...@fluxnic.net wrote: But what if we store appended objects in OBJ_REF_DELTA format where base ref is empty tree/commit and cached by sha1_file.c? I don't follow you here. Missing objects need to be added to the pack, they can't be cached anywhere. I use ref-delta as an alternate escape hatch to store missing commits and trees in unparsed format. In order to do that, I need a base ref SHA-1 and we can create and store SHA-1 of empty commit and emptry tree in sha1_file.c (because empty commit is not in a valid format and can't be parsed and stored in v3). So the result pack is still thin but it should only lack at most two objects: empty commit and empty tree. Thinking again this is much uglier than escape hatches to v3 tables.. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
