* [PATCH RESEND] git-gui: Fix merge conflict display error when filename contains spaces
From: Jens Lehmann @ 2009-03-20 7:52 UTC (permalink / raw)
To: git
When a merge conflict occurs in a file with spaces in the filename, git-gui showed wrongly "LOCAL: deleted".
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Resending this patch, as i have not received any reply so far.
To reproduce the error with git 1.6.2.1.136.g8e24, i used the following commands:
mkdir spaces
cd spaces/
git init
echo "a" >file\ with\ spaces
git add file\ with\ spaces
git commit -m a .
git checkout -b b
echo "b" >file\ with\ spaces
git commit -m b .
git checkout master
echo "c" >file\ with\ spaces
git commit -m c .
git merge b
git gui
git gui doesn't show the conflict markers as it should, displaying "LOCAL: deleted" instead (but an older git-gui works as expected).
Jens
git-gui/lib/mergetool.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/mergetool.tcl b/git-gui/lib/mergetool.tcl
index eb2b4b5..3e1b42b 100644
--- a/git-gui/lib/mergetool.tcl
+++ b/git-gui/lib/mergetool.tcl
@@ -88,7 +88,7 @@ proc merge_load_stages {path cont} {
set merge_stages(3) {}
set merge_stages_buf {}
- set merge_stages_fd [eval git_read ls-files -u -z -- $path]
+ set merge_stages_fd [eval git_read ls-files -u -z -- {$path}]
fconfigure $merge_stages_fd -blocking 0 -translation binary -encoding binary
fileevent $merge_stages_fd readable [list read_merge_stages $merge_stages_fd $cont]
--
1.6.2.1.215.g5d16f
^ permalink raw reply related
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Christian Couder @ 2009-03-20 7:41 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Git List, Sam Hocevar, Alexandre Bourget, Nicolas Sebrecht
In-Reply-To: <5b4295c484a9659d1c5813e1859f192c34d6a99e.1237506346.git.nicolas.s-dev@laposte.net>
Le vendredi 20 mars 2009, Nicolas Sebrecht a écrit :
> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
> ---
> po/fr.po | 21 ++++++++++-----------
> 1 files changed, 10 insertions(+), 11 deletions(-)
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Shawn,
Could you add Sam's patch and this one on top of Sam's patch?
Could you also squash the following change:
s/Essayez de récupéré/Essayez de récupérer/
If you prefer me to send yet another patch for this last change, please tell
me.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Sam Hocevar @ 2009-03-20 7:37 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Git List, Christian Couder, Alexandre Bourget
In-Reply-To: <5b4295c484a9659d1c5813e1859f192c34d6a99e.1237506346.git.nicolas.s-dev@laposte.net>
On Fri, Mar 20, 2009, Nicolas Sebrecht wrote:
Last minor fix :
> -msgstr "Révocation en cours des fichiers selectionnés"
> +msgstr "Inversion en cours des fichiers selectionnés"
^
sélectionnés
--
Sam.
^ permalink raw reply
* Git no longer reads attributes from the index properly
From: Brian Downing @ 2009-03-20 7:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Linus Torvalds, msysgit
As of 34110cd4e394e3f92c01a4709689b384c34645d8, (2008-03-06, just over a
year ago), Git no longer reads attributes from the index properly in all
cases. This breaks initial checkouts where .gitattribute information is
required to get a good checkout. [I'm also copying the msysgit guys on
this, since they are probably the primary customers of autocrlf and the
crlf attributes, though the problem exists in core Git.]
This support for reading attributes from the index in addition to the
working directory was added in 1a9d7e9b484e77436edc7f5cacd39c24ec605e6d,
on 2007-08-14:
commit 1a9d7e9b484e77436edc7f5cacd39c24ec605e6d
Author: Junio C Hamano <gitster@pobox.com>
Date: Tue Aug 14 01:41:02 2007 -0700
attr.c: read .gitattributes from index as well.
This makes .gitattributes files to be read from the index when
they are not checked out to the work tree. This is in line with
the way we always allowed low-level tools to operate in sparsely
checked out work tree in a reasonable way.
It swaps the order of new file creation and converting the blob
to work tree representation; otherwise when we are in the middle
of checking out .gitattributes we would notice an empty but
unwritten .gitattributes file in the work tree and will ignore
the copy in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This worked until the following commit:
34110cd4e394e3f92c01a4709689b384c34645d8 is first bad commit
commit 34110cd4e394e3f92c01a4709689b384c34645d8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Mar 6 18:12:28 2008 -0800
Make 'unpack_trees()' have a separate source and destination index
We will always unpack into our own internal index, but we will take the
source from wherever specified, and we will optionally write the result
to a specified index (optionally, because not everybody even _wants_ any
result: the index diffing really wants to just walk the tree and index
in parallel).
This ends up removing a fair number more lines than it adds, for the
simple reason that we can now skip all the crud that tried to be
oh-so-careful about maintaining our position in the index as we were
traversing and modifying it. Since we don't actually modify the source
index any more, we can just update the 'o->pos' pointer without worrying
about whether an index entry got removed or replaced or added to.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately I don't have the foggiest on how to fix this. However, I
did write a new test case to catch this bug, as the existing ones were
insufficiently destructive to trigger it. This test case is ugly, uses
porcelain, and is probably overly-destructive, but it does show the
problem. It fails on 34110cd4 and succeeds on 34110cd4^.
I don't expect the test case can be accepted as-is, but regardless:
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
t/t0020-crlf.sh | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 1be7446..749cd09 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -429,6 +429,25 @@ test_expect_success 'in-tree .gitattributes (4)' '
}
'
+test_expect_success 'in-tree .gitattributes (5)' '
+
+ rm .git/index &&
+ git clean -d -x -f &&
+ git checkout &&
+
+ if remove_cr one >/dev/null
+ then
+ echo "Eh? one should not have CRLF"
+ false
+ else
+ : happy
+ fi &&
+ remove_cr three >/dev/null || {
+ echo "Eh? three should still have CRLF"
+ false
+ }
+'
+
test_expect_success 'invalid .gitattributes (must not crash)' '
echo "three +crlf" >>.gitattributes &&
--
1.5.6.3
^ permalink raw reply related
* Re: How to commit changes if remote repository changed directory structure?
From: Jeff King @ 2009-03-20 7:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, andholt, git
In-Reply-To: <7vljr04qnw.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 20, 2009 at 12:08:51AM -0700, Junio C Hamano wrote:
> > First, commit your changes. Then merge the other developer's changes. :)
>
> We should probably point out to new people that "first commit and then
> worry about merges after your changes are safely committed" is always how
> people would "go about" anything.
Yes, absolutely.
Most of the current documentation focuses on being a reference to
particular commands or tasks. But this is more of a "philosophy of
working with git" item. I guess it should go in the user manual
somewhere. Cc'ing Bruce, who may have some comments.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Mike Hommey @ 2009-03-20 7:13 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Git List, Sam Hocevar, Christian Couder, Alexandre Bourget
In-Reply-To: <5b4295c484a9659d1c5813e1859f192c34d6a99e.1237506346.git.nicolas.s-dev@laposte.net>
On Fri, Mar 20, 2009 at 01:54:02AM +0100, Nicolas Sebrecht wrote:
>
>
> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
> ---
> po/fr.po | 21 ++++++++++-----------
> 1 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/po/fr.po b/po/fr.po
> index eb5f68e..2f96054 100644
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -316,11 +316,11 @@ msgstr "Indexer toutes modifications"
>
> #: git-gui.sh:2479
> msgid "Unstage From Commit"
> -msgstr "Désindexer"
> +msgstr "Retirer de l'index"
IMHO, we should find a better way to say that than to use the "index"
word at all. This obviously applies to all uses of "index" in french
where we avoided it in english.
OTOH, the best I can find for "staging area" is "zone de préparation",
and that doesn't help finding a word for stage and unstage.
Mike
^ permalink raw reply
* Re: How to commit changes if remote repository changed directory structure?
From: Junio C Hamano @ 2009-03-20 7:08 UTC (permalink / raw)
To: Jeff King; +Cc: andholt, git
In-Reply-To: <20090320060926.GC27008@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Mar 19, 2009 at 06:17:15PM -0700, andholt wrote:
>
>> I have a lot of local changes to add, commit, and push. Right now our
>> directory structure is 1/2/3. Another developer decided to move everything
>> up one level, so used git move to move 3 to 2, and removed 3, so now the
>> level is 1/2. However, locally, all of my changes are in 1/2/3.
>>
>> I want to commit my changes and merge them into the new directory structure.
>> How would I go about doing that?
>
> First, commit your changes. Then merge the other developer's changes. :)
We should probably point out to new people that "first commit and then
worry about merges after your changes are safely committed" is always how
people would "go about" anything.
^ permalink raw reply
* Re: [PATCH v2 1/2] Introduce config variable "diff.defaultOptions"
From: Jeff King @ 2009-03-20 7:01 UTC (permalink / raw)
To: Keith Cascio; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.GSO.2.00.0903170825340.16242@kiwi.cs.ucla.edu>
On Tue, Mar 17, 2009 at 09:05:18AM -0700, Keith Cascio wrote:
> In order to answer your questions as convincingly as possible, I wrote up a
> one-page PDF document, downloadable here:
> http://preview.tinyurl.com/c769dd
Thanks for following up on this. And I appreciate that it is probably
nicer to compose in whatever you used to make this PDF due to enhanced
typography and linked footnotes, but posting a link to a PDF has a few
downsides:
- the text in the PDF does not become part of the list archive; if
your tinyurl or your hosted file ever goes away, the content of
your message is permanently lost
- it makes it very difficult for readers to reply inline to your
comments
So please just send text emails in the future.
This time, however, I converted your PDF to text so I could reply.
Your PDF said:
> No matter which implementation, we all agree the semantics are "pretend
> as if the options in [diff.defaultOptions] were prepended to the command
> line" [1]. That requirement is subject neither to confusion nor doubt.
> An implementation is acceptable only if it delivers exactly that
> behavior to the user.
OK, good, I think we are in agreement there.
> Git's diff options processing scheme is a mature[2], versatile
> instrument relied upon by at least 47 client codepaths. The API it
> provides for recording user intent to an instance of struct diff_options
> entails the following steps[3]:
>
> 1) to prepare the structure for recording, call diff_setup() once
>
> 2) to record user intention, write to the structure[4], calling
> diff_opt_parse() as needed
I think there is a step 1.5, where callers can record their own
"default" intentions -- things that this particular caller will default
to, but which users can override via command-line options. E.g., "git
log" tweaks several options in cmd_log_init, such as turning on
ALLOW_TEXTCONV and RECURSIVE.
> 3) to prepare the structure for "playback", call diff_setup_done() once
>
> 4) to test user intention, read from the structure
OK, makes sense.
> Git's code is already equipped to react to every kind of user intention
> during step 2.
More or less. I think in our past discussion, it came about that there
are some things the user cannot say, like undoing certain options. This
could be a problem if a caller defaults options to something un-doable.
For example, I don't think there is a way to turn off OPT_RECURSIVE in
git-log. In practice, this hasn't been a problem.
> An attractive (but hopelessly flawed) strategy is to pre-load the
> structure with defaultOptions before step 2. Step 1, diff_setup(), is
> the only place to do that, since the client starts overwriting as soon
> as diff_setup() returns.
I don't agree that it is hopelessly flawed. It requires a new call at
each callsite to say "I have set up my defaults, now take the user
defaults from the config, before I proceed to step 2 and parse the
user intentions". Which sounds awful to add a new call at each site,
but I am not sure that is not necessary anyway.
I don't know that all callsites will _want_ to respect such a config
option, especially not plumbing. So any callsite is going to have to opt
into this functionality anyway.
> Some aspects of user intention dictate whether or not to perform the
> pre-load at all, most notably: which Git command the user invoked (also
> switches). But at step 1, inside diff_setup(), we don't know the user's
> full intention yet, so we can't decide whether or not to perform the
> pre-load.
I think I suggested last time that the idea of whether or not to perform
the pre-load doesn't _have_ to come from the same set of user intention.
That is, in the call
git [git-options] diff [diff-options]
we actually parse [git-options] and [diff-options] at different times.
Pre-load intention can go into [git-options], which avoids this
dependency cycle.
> This could tempt an undisciplined programmer to try to peek ahead at
> part of the user's intention before the code sees it in its normal
> course. That would be a disaster because it would undermine the
> integrity, not to mention beauty, of Git's entire initialization scheme.
> It would be a cheap hack; an inelegant, fragile, ugly, and utterly
> half-baked attempt to bypass and circumvent the existing architecture.
Your poetry aside, I agree that way madness lies.
> My proposal:
>
> a) patiently accumulates user intention via Git's well-established
> initialization scheme, never needing to peek ahead or misbehave in any
> way, thus attaining harmony.
>
> b) postpones the decision whether or not to load defaultOptions until
> step 3, diff_setup_done(), after we've had every opportunity to examine
> user intention, but loads them effectively underneath any explicit
> command line options, thereby fulfilling the agreed upon semantic
> obligation.
>
> c) is inspired by a simple, powerful, easy-to-understand, and popular
> metaphor: layer flattening.
>
> Why, oh why do some people think there's an "easier" way[1]?!
Because I outlined it above?
Look, I am not opposed to layer flattening if that's what is required to
get it right. But consider the downside of layer flattening: we must
always record intent-to-change when making a change to the struct (i.e.,
the "mask" variable in your original patches). This is fine for members
hidden behind macros, but there are a lot of members that are assigned
to directly. We would need to:
1. Introduce new infrastructure for assigning to these members.
2. Fix existing locations by converting them to this infrastructure.
3. Introduce some mechanism to help future callers get it right (since
otherwise assigning directly is a subtle bug).
This is elementary encapsulation; in a language with better OO support,
you would hide all of your struct members behind accessors. But this is
C, and a dialect of C where that doesn't usually happen. So I think it
is going to introduce a lot of code changes, and the resulting code will
not look as much like the rest of git as it once did.
So what I am suggesting is that _if_ there is an easier way to do it,
then it is worth exploring.
-Peff
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Junio C Hamano @ 2009-03-20 6:57 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Johannes Schindelin, Petr Baudis,
Andreas Gruenbacher, git
In-Reply-To: <20090320060545.GB27008@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:
>
>> So yea, you can create a branch named "foo@{1}".
>
> But you can't actually refer to it:
>
> $ git branch foo@{1}
> $ git show foo@{1} --
> fatal: bad revision 'foo@{1}'
>
> which implies that nobody is actually using it for anything.
I think you are right. It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.
^ permalink raw reply
* Re: [PATCH] Re: git-gui: various French translation fixes
From: Christian Couder @ 2009-03-20 6:45 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Sam Hocevar, Git List, Alexandre Bourget
In-Reply-To: <20090319183839.GA12913@vidovic>
Le jeudi 19 mars 2009, Nicolas Sebrecht a écrit :
> On Thu, Mar 19, 2009 at 01:49:02PM +0100, Sam Hocevar wrote:
> > On Thu, Mar 19, 2009, Sam Hocevar wrote:
> > > On Thu, Mar 19, 2009, Christian Couder wrote:
> > > > > > #: git-gui.sh:2484 lib/index.tcl:410
> > > > > > msgid "Revert Changes"
> > > > > > -msgstr "Annuler les modifications (revert)"
> > > > > > +msgstr "Révoquer les modifications"
> > > > >
> > > > > I am not sure that "Révoquer" is better than "Annuler".
> > > >
> > > > Perhaps "Inverser"?
>
> [...]
>
> > Sorry, I misread the Wikipedia interface because I wasn't logged in
> > and only admins can truly revert edits.
>
> I don't think that we have to conform to Wikipédia.
>
> > So it does have "revert" (to
> > cancel an edit) and "undo" (to perform the opposite edit of a given
> > edit), which get translated to "révoquer" and "défaire". I therefore
> > think "révoquer" is just as good as the others.
>
> I disagree here.
>
> "Annuler", "Révoquer", "Inverser" or "Défaire" usualy stands for the
> same thing but :
> - thoses words doesn't have stricly the same meanings ;
> - we are in a special case here because of the underlying technical
> result.
>
> We should care that the revert operation does *not* remove a commit but
> add a new one (this makes sense to Git). As a consequence, we should
> avoid "Annuler", "Révoquer" and "Défaire".
>
> "Inverser" looks like the best translation.
Yeah, I agree with that reasoning.
Regards,
Christian.
^ permalink raw reply
* Have you heard about it?
From: Madge @ 2009-03-20 6:35 UTC (permalink / raw)
To: git
I hope you haven.t been there http://isyxcz.globalantiterror.com
^ permalink raw reply
* Re: How to commit changes if remote repository changed directory structure?
From: Jeff King @ 2009-03-20 6:09 UTC (permalink / raw)
To: andholt; +Cc: git
In-Reply-To: <22612715.post@talk.nabble.com>
On Thu, Mar 19, 2009 at 06:17:15PM -0700, andholt wrote:
> I have a lot of local changes to add, commit, and push. Right now our
> directory structure is 1/2/3. Another developer decided to move everything
> up one level, so used git move to move 3 to 2, and removed 3, so now the
> level is 1/2. However, locally, all of my changes are in 1/2/3.
>
> I want to commit my changes and merge them into the new directory structure.
> How would I go about doing that?
First, commit your changes. Then merge the other developer's changes. :)
This is exactly the sort of case that git's rename detection should
handle; it should detect that the other side renamed files, and then
consider your changes against the newly named files. The only thing it
_won't_ handle is new files that you added in 1/2/3. You will have to
manually move them to 1/2 as part of the merge (there has been
discussion of "detect that this whole directory seems to have had its
content moved and automatically move new files", but the patches have
not been accepted).
-Peff
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Jeff King @ 2009-03-20 6:05 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Junio C Hamano, Petr Baudis,
Andreas Gruenbacher, git
In-Reply-To: <20090320004029.GX23521@spearce.org>
On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:
> So yea, you can create a branch named "foo@{1}".
But you can't actually refer to it:
$ git branch foo@{1}
$ git show foo@{1} --
fatal: bad revision 'foo@{1}'
which implies that nobody is actually using it for anything.
-Peff
^ permalink raw reply
* [PATCH] make oneline reflog dates more consistent with multiline format
From: Jeff King @ 2009-03-20 6:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, demerphq, Git
In-Reply-To: <20090320052802.GA27714@coredump.intra.peff.net>
The multiline reflog format (e.g., as shown by "git log -g")
will show HEAD@{<date>} rather than HEAD@{<count>} in two
situations:
1. If the user gave branch@{<date>} syntax to specify the
reflog
2. If the user gave a --date=<format> specifier
It uses the "normal" date format in case 1, and the
user-specified format in case 2.
The oneline reflog format (e.g., "git reflog show" or "git
log -g --oneline") will show the date in the same two
circumstances. However, it _always_ shows the date as a
relative date, and it always ignores the timezone.
In case 2, it seems ridiculous to trigger the date but use a
format totally different from what the user requested.
For case 1, it is arguable that the user might want to see
the relative date by default; however, the multiline version
shows the normal format.
This patch does three things:
- refactors the "relative_date" parameter to
show_reflog_message to be an actual date_mode enum,
since this is how it is used (it is passed to show_date)
- uses the passed date_mode parameter in the oneline
format (making it consistent with the multiline format)
- does not ignore the timezone parameter in oneline mode
Signed-off-by: Jeff King <peff@peff.net>
---
reflog-walk.c | 12 +++++---
reflog-walk.h | 5 +++-
t/t1411-reflog-show.sh | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 78 insertions(+), 6 deletions(-)
create mode 100755 t/t1411-reflog-show.sh
diff --git a/reflog-walk.c b/reflog-walk.c
index f751fdc..fd065f4 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -242,7 +242,7 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
}
void show_reflog_message(struct reflog_walk_info* info, int oneline,
- int relative_date)
+ enum date_mode dmode)
{
if (info && info->last_commit_reflog) {
struct commit_reflog *commit_reflog = info->last_commit_reflog;
@@ -251,8 +251,10 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline,
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
if (oneline) {
printf("%s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || relative_date)
- printf("%s", show_date(info->timestamp, 0, 1));
+ if (commit_reflog->flag || dmode)
+ printf("%s", show_date(info->timestamp,
+ info->tz,
+ dmode));
else
printf("%d", commit_reflog->reflogs->nr
- 2 - commit_reflog->recno);
@@ -260,10 +262,10 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline,
}
else {
printf("Reflog: %s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || relative_date)
+ if (commit_reflog->flag || dmode)
printf("%s", show_date(info->timestamp,
info->tz,
- relative_date));
+ dmode));
else
printf("%d", commit_reflog->reflogs->nr
- 2 - commit_reflog->recno);
diff --git a/reflog-walk.h b/reflog-walk.h
index 7ca1438..74c9096 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -1,11 +1,14 @@
#ifndef REFLOG_WALK_H
#define REFLOG_WALK_H
+#include "cache.h"
+
extern void init_reflog_walk(struct reflog_walk_info** info);
extern int add_reflog_for_walk(struct reflog_walk_info *info,
struct commit *commit, const char *name);
extern void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit);
-extern void show_reflog_message(struct reflog_walk_info *info, int, int);
+extern void show_reflog_message(struct reflog_walk_info *info, int,
+ enum date_mode);
#endif
diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
new file mode 100755
index 0000000..c18ed8e
--- /dev/null
+++ b/t/t1411-reflog-show.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='Test reflog display routines'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo content >file &&
+ git add file &&
+ test_tick &&
+ git commit -m one
+'
+
+cat >expect <<'EOF'
+Reflog: HEAD@{0} (C O Mitter <committer@example.com>)
+Reflog message: commit (initial): one
+EOF
+test_expect_success 'log -g shows reflog headers' '
+ git log -g -1 >tmp &&
+ grep ^Reflog <tmp >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+e46513e HEAD@{0}: commit (initial): one
+EOF
+test_expect_success 'oneline reflog format' '
+ git log -g -1 --oneline >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+Reflog: HEAD@{Thu Apr 7 15:13:13 2005 -0700} (C O Mitter <committer@example.com>)
+Reflog message: commit (initial): one
+EOF
+test_expect_success 'using @{now} syntax shows reflog date (multiline)' '
+ git log -g -1 HEAD@{now} >tmp &&
+ grep ^Reflog <tmp >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+e46513e HEAD@{Thu Apr 7 15:13:13 2005 -0700}: commit (initial): one
+EOF
+test_expect_success 'using @{now} syntax shows reflog date (oneline)' '
+ git log -g -1 --oneline HEAD@{now} >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+Reflog: HEAD@{1112911993 -0700} (C O Mitter <committer@example.com>)
+Reflog message: commit (initial): one
+EOF
+test_expect_success 'using --date= shows reflog date (multiline)' '
+ git log -g -1 --date=raw >tmp &&
+ grep ^Reflog <tmp >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+e46513e HEAD@{1112911993 -0700}: commit (initial): one
+EOF
+test_expect_success 'using --date= shows reflog date (oneline)' '
+ git log -g -1 --oneline --date=raw >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.6.2.1.342.gdbf4
^ permalink raw reply related
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Sverre Rabbelier @ 2009-03-20 5:59 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Junio C Hamano, Petr Baudis,
Andreas Gruenbacher, git
In-Reply-To: <20090320004450.GY23521@spearce.org>
Heya,
On Fri, Mar 20, 2009 at 01:44, Shawn O. Pearce <spearce@spearce.org> wrote:
> In hindsight, I wish we had reserved all of the "fun" characters
> like !@#$%^&*():;~'"\ and prevented them from ever appearing in a
> ref name.
Maybe we should add a --pedantic which whines when you use any of
those in a branch name; oh wait, wrong project... :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Gnome chose Git
From: Jeff King @ 2009-03-20 5:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: demerphq, Git
In-Reply-To: <20090319214317.GU23521@spearce.org>
On Thu, Mar 19, 2009 at 02:43:17PM -0700, Shawn O. Pearce wrote:
> demerphq <demerphq@gmail.com> wrote:
> > Outside of parsing the reflog directly, (which feels wrong and dirty
> > to me), how does one find out the times that a reflog entry was
> > created?
> >
> > The closest thing i could find was git log -g, but that shows the time
>
> git reflog -g branch@{now}
>
> the @{now} suffix is the magic to make it show the time.
Yuck. It would be nice to just have a "Reflog date" header that you
could depend on, like:
diff --git a/reflog-walk.c b/reflog-walk.c
index f751fdc..cb7c66b 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -269,6 +269,8 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline,
- 2 - commit_reflog->recno);
printf("} (%s)\nReflog message: %s",
info->email, info->message);
+ printf("Reflog date: %s\n",
+ show_date(info->timestamp, info->tz, relative_date));
}
}
}
Then you could just do:
$ git log --date=raw -g
Looking at making this trivial patch, though, it seems there is a bug
with the relative_date parameter. It is really a date_mode enum. In the
multi-line format, we feed it to show_date. But in the oneline mode, we
use it to decide whether to show the date, but then always pass the
"relative" date mode. So you get:
$ git log --oneline -g origin/master | head -n 1
e986ceb refs/remotes/origin/master@{0}: fetch origin: fast forward
$ git log --oneline -g --date=relative origin/master | head -n 1
e986ceb refs/remotes/origin/master@{2 days ago}: fetch origin: fast forward
$ git log --oneline -g --date=raw origin/master | head -n 1
e986ceb refs/remotes/origin/master@{2 days ago}: fetch origin: fast forward
Hmm. It seems to drop the TZ, too. I'll whip up a patch.
I guess my original "extra reflog header" isn't terribly useful, then:
you can always just pass --date=raw and parse it from the branch@{}
syntax.
-Peff
^ permalink raw reply related
* Re: Adding History
From: John Tapsell @ 2009-03-20 5:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Roger Garvin, git
In-Reply-To: <20090319174732.GS23521@spearce.org>
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> Roger Garvin <yoyodyn@gmail.com> wrote:
>> Is there a way to add history to a repository?
>> We have just started using git, where before we had nothing but backup
>> directories all over the place. We created the git repository using our
>> existing source directory. Is there a way to now go and add some of the backup
>> source directories to the history? Or would this break all the SHA1 of the
>> current objects?
>
> Right, you need to change the SHA-1 of all of the commits in order
> to insert history in the past.
>
>> I am not sure it would be worth it at this point. But we are
>> still pretty early in our use of git so now would be the easiest time.
>
> You have two options:
Couldn't you just create import the whole tree and then rebase on top of it?
^ permalink raw reply
* Re: Git Large Object Support Proposal
From: Jeff King @ 2009-03-20 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git list
In-Reply-To: <7vzlfh5b7y.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 19, 2009 at 04:44:49PM -0700, Junio C Hamano wrote:
> Aha, that sounds like you can just maintain a set of out-of-tree symbolic
> links that you keep track of, and let other people (e.g. rsync) deal with
> the complexity of managing that side of the world.
>
> And I think you can start experimenting it without any change to the core
> datastructures. In your single-page web site in which its sole html file
> embeds an mpeg movie, you keep track of these two things in git:
>
> porn-of-the-day.html
> porn-of-the-day.mpg -> ../media/6066f5ae75ec.mpg
>
> and any time you want to feed a new movie, you update the symlink to a
> different one that lives outside the source-controlled tree, while
> arranging the link target to be updated out-of-band.
I have a repo like this (not porn, but large files :) ) and I use a
similar solution. Instead of large blobs, I have stub files containing a
URL, and the make process pulls them as necessary. It works pretty well
in practice. I don't bother with naming the files by sha-1 but instead
give them human-readable names, since in my case they are generally
immutable (i.e., one a name is assigned, the content doesn't change).
-Peff
^ permalink raw reply
* Re: git am from scratch
From: Jeff King @ 2009-03-20 4:39 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200903200206.24555.agruen@suse.de>
On Fri, Mar 20, 2009 at 02:06:24AM +0100, Andreas Gruenbacher wrote:
> On Thursday, 19 March 2009 22:02:14 Jeff King wrote:
> > Yikes. Out of curiosity, what did you use to do the CVS import?
>
> git-cvsimport
Ah. It sounds like you have already resolved all of your issues by
munging the resulting history, but you may have better success on a
complex history with a different tool like cvs2git or parsecvs (even if
you have fixed it, you may want to investigate them to double-check your
result).
-Peff
^ permalink raw reply
* Re: [PATCH] git-am: teach git-am to apply a patch to an unborn branch
From: Jeff King @ 2009-03-20 4:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090320071231.6117@nanako3.lavabit.com>
On Fri, Mar 20, 2009 at 07:12:31AM +0900, Nanako Shiraishi wrote:
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Thanks for picking up this topic. It looks sane overall.
> - parent=$(git rev-parse --verify HEAD) &&
> + if parent=$(git rev-parse --verify -q HEAD)
> + then
> + pparent="-p $parent"
> + else
> + echo >&2 "applying to an empty history"
> + parent= pparent=
> + fi &&
Note that the '&&' here is now pointless, since one side of the
conditional will always be true. We are losing the ability to detect
errors besides "HEAD does not point to a valid object", but I don't
think there is a way to tell the difference from the exit code of
rev-parse.
-Peff
^ permalink raw reply
* Re: [PATCH 0/5] repack improvements
From: Brandon Casey @ 2009-03-20 4:05 UTC (permalink / raw)
To: gitster; +Cc: git, drafnel
In-Reply-To: <t_s5aa51o2kq_ePRWgLTEkVg4HqH1dQa6_mVq4djPPG4Vxylm2hNqmx7fPC2W5AsfcXg83DYbGc@cipher.nrlssc.navy.mil>
Sorry, I forgot the sign-off on these patches. If you decide to apply,
please add it or tell me to resend.
thanks,
-brandon
^ permalink raw reply
* [PATCH 5/5] Remove --kept-pack-only option and associated infrastructure
From: Brandon Casey @ 2009-03-20 3:47 UTC (permalink / raw)
To: gitster; +Cc: git, drafnel
In-Reply-To: <t_s5aa51o2kq_ePRWgLTEtCnzveAKdblNoXw2p9yc1N22fpuARDjOh9wRXpwEKvultyJoNzUWBY@cipher.nrlssc.navy.mil>
This option to pack-objects/rev-list was created to improve the -A and -a
options of repack. It was found to be lacking in that it did not provide
the ability to differentiate between local and non-local kept packs, and
found to be unnecessary since objects residing in local kept packs can be
filtered out by the --honor-pack-keep option.
---
builtin-pack-objects.c | 1 -
cache.h | 1 -
revision.c | 9 +--------
revision.h | 1 -
sha1_file.c | 21 +--------------------
5 files changed, 2 insertions(+), 31 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 22d69ef..24f96f0 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -2200,7 +2200,6 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp("--unpacked", arg) ||
- !strcmp("--kept-pack-only", arg) ||
!strcmp("--reflog", arg) ||
!strcmp("--all", arg)) {
use_internal_rev_list = 1;
diff --git a/cache.h b/cache.h
index 39789ee..a94cf67 100644
--- a/cache.h
+++ b/cache.h
@@ -646,7 +646,6 @@ extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned l
extern int move_temp_to_file(const char *tmpfile, const char *filename);
extern int has_sha1_pack(const unsigned char *sha1);
-extern int has_sha1_kept_pack(const unsigned char *sha1);
extern int has_sha1_file(const unsigned char *sha1);
extern int has_loose_object_nonlocal(const unsigned char *sha1);
diff --git a/revision.c b/revision.c
index f5771c7..b6215cc 100644
--- a/revision.c
+++ b/revision.c
@@ -1106,10 +1106,6 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->edge_hint = 1;
} else if (!strcmp(arg, "--unpacked")) {
revs->unpacked = 1;
- revs->kept_pack_only = 0;
- } else if (!strcmp(arg, "--kept-pack-only")) {
- revs->unpacked = 1;
- revs->kept_pack_only = 1;
} else if (!prefixcmp(arg, "--unpacked=")) {
die("--unpacked=<packfile> no longer supported.");
} else if (!strcmp(arg, "-r")) {
@@ -1679,10 +1675,7 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
{
if (commit->object.flags & SHOWN)
return commit_ignore;
- if (revs->unpacked &&
- (revs->kept_pack_only
- ? has_sha1_kept_pack(commit->object.sha1)
- : has_sha1_pack(commit->object.sha1)))
+ if (revs->unpacked && has_sha1_pack(commit->object.sha1))
return commit_ignore;
if (revs->show_all)
return commit_show;
diff --git a/revision.h b/revision.h
index ad123d7..6e98b71 100644
--- a/revision.h
+++ b/revision.h
@@ -50,7 +50,6 @@ struct rev_info {
edge_hint:1,
limited:1,
unpacked:1,
- kept_pack_only:1,
boundary:2,
left_right:1,
rewrite_parents:1,
diff --git a/sha1_file.c b/sha1_file.c
index 4563173..a354f06 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1919,8 +1919,7 @@ off_t find_pack_entry_one(const unsigned char *sha1,
return 0;
}
-static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
- int kept_pack_only)
+static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
{
static struct packed_git *last_found = (void *)1;
struct packed_git *p;
@@ -1932,8 +1931,6 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
p = (last_found == (void *)1) ? packed_git : last_found;
do {
- if (kept_pack_only && !p->pack_keep)
- goto next;
if (p->num_bad_objects) {
unsigned i;
for (i = 0; i < p->num_bad_objects; i++)
@@ -1973,16 +1970,6 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
return 0;
}
-static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
-{
- return find_pack_ent(sha1, e, 0);
-}
-
-static int find_kept_pack_entry(const unsigned char *sha1, struct pack_entry *e)
-{
- return find_pack_ent(sha1, e, 1);
-}
-
struct packed_git *find_sha1_pack(const unsigned char *sha1,
struct packed_git *packs)
{
@@ -2456,12 +2443,6 @@ int has_sha1_pack(const unsigned char *sha1)
return find_pack_entry(sha1, &e);
}
-int has_sha1_kept_pack(const unsigned char *sha1)
-{
- struct pack_entry e;
- return find_kept_pack_entry(sha1, &e);
-}
-
int has_sha1_file(const unsigned char *sha1)
{
struct pack_entry e;
--
1.6.2.16.geb16e
^ permalink raw reply related
* [PATCH 4/5] t7700-repack: repack -a now works properly, expect success from test
From: Brandon Casey @ 2009-03-20 3:47 UTC (permalink / raw)
To: gitster; +Cc: git, drafnel
In-Reply-To: <t_s5aa51o2kq_ePRWgLTEvwR8O51ATzGH2_NEfAeCgOx3i1IYGfgLg3-dTPOh68RhaeQgBB9s2g@cipher.nrlssc.navy.mil>
Thanks to Junio's rework of the --unpacked= option of pack-objects/rev-list
git-repack now properly packs objects from alternate repositories even when
the local repository contains packs.
---
t/t7700-repack.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 31e6d22..28fc87a 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -69,7 +69,7 @@ test_expect_success 'packed obs in alt ODB are repacked even when local repo is
done
'
-test_expect_failure 'packed obs in alt ODB are repacked when local repo has packs' '
+test_expect_success 'packed obs in alt ODB are repacked when local repo has packs' '
rm -f .git/objects/pack/* &&
echo new_content >> file1 &&
git add file1 &&
--
1.6.2.16.geb16e
^ permalink raw reply related
* [PATCH 0/5] repack improvements
From: Brandon Casey @ 2009-03-20 3:47 UTC (permalink / raw)
To: gitster; +Cc: git, drafnel
In-Reply-To: <EblkEXbcYUWby1OEDup9n0l6lbwNL-4-jyt02Cjab2pqLqekAUji0w@cipher.nrlssc.navy.mil>
As I mentioned in a previous email, the recent changes to
pack-objects/rev-list partially fixed one repacking flaw, but introduced 2
others. There were actually two emails, but the first one never made it
to the list.
There existed a flaw that prevented repack from properly repacking objects
contained in packs from alternate repositories if the local repository
contained any non-kept packs. This was fixed by the --kept-pack-only feature,
in exchange for not being able to pack objects contained in alternate packs
which had a keep file. Since the user may not have control over the referenced
object database, I think it is fair not to the honor the keep files in that
case.
Additionally, if repack told pack-objects to loosen unreferenced objects,
it would even loosen objects residing in alternate packs. They would then be
immediately deleted by the call to prune-packed though.
The solution I chose is actually to fall back to the --honor-pack-keep option
and to stop using the --kept-pack-only option. pack-objects already iterates
over every object added for packing and searches the pack array to check
whether it is already packed, so for the case where no keep files are used,
there is actually one less iteration through the pack array for each commit.
But one more (?) for each object referenced by a commit that is packed in a
pack with a .keep file.
So this keeps the local and keep_pack decision making in pack-objects. The
other way would be to move the --local option over into rev-list and teach
the pack lookup machinery to differentiate between local and non-local packs.
Not sure which is better, but this was easier.
I think there is still one case where an object will be loosened unnecessarily.
If an unreferenced object exists in a local pack _and_ in an alternate object
database, then I believe it will be loosened and then pruned. To fix it,
loosen_unused_packed_objects and add_objects_in_unpacked_packs would have to
iterate through the non-local packs to check whether they contained the object
before loosening/repacking it. Probably won't happen often in practice though.
Also, I think the --kept-pack-only option is now not necessary. The last
patch removes the --kept-pack-only feature /ducks and can be dropped if you
think this feature may be useful in the future.
Brandon Casey (5):
t7700-repack: add two new tests demonstrating repacking flaws
git-repack.sh: don't use --kept-pack-only option to pack-objects
pack-objects: only repack or loosen objects residing in "local" packs
t7700-repack: repack -a now works properly, expect success from test
Remove --kept-pack-only option and associated infrastructure
builtin-pack-objects.c | 5 ++---
cache.h | 1 -
git-repack.sh | 6 +-----
revision.c | 9 +--------
revision.h | 1 -
sha1_file.c | 21 +--------------------
t/t7700-repack.sh | 46 +++++++++++++++++++++++++++++++++++++++++++++-
7 files changed, 50 insertions(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 1/5] t7700-repack: add two new tests demonstrating repacking flaws
From: Brandon Casey @ 2009-03-20 3:47 UTC (permalink / raw)
To: gitster; +Cc: git, drafnel
In-Reply-To: <t_s5aa51o2kq_ePRWgLTEkVg4HqH1dQa6_mVq4djPPG4Vxylm2hNqmx7fPC2W5AsfcXg83DYbGc@cipher.nrlssc.navy.mil>
1) The new --kept-pack-only mechansim of rev-list/pack-objects has
replaced --unpacked=. This new mechansim does not operate solely on
"local" packs now. The result is that objects residing in an alternate
pack which has a .keep file will not be repacked with repack -a.
This flaw is only apparent when a commit object is the one residing in
an alternate kept pack.
2) The 'repack unpacked objects' and 'loosen unpacked objects' mechanisms
of pack-objects, i.e. --keep-unreachable and --unpack-unreachable,
now do not operate solely on local packs. The --keep-unreachable
option no longer has any callers, but --unpack-unreachable is used when
repack is called with '-A -d' and the local repo has existing packs.
In this case, objects residing in alternate, not-kept packs will be
loosened, and then immediately deleted by repack's call to
prune-packed.
The test must manually call pack-objects to avoid the call to
prune-packed that is made by repack when -d is used.
---
t/t7700-repack.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index f5682d6..e869995 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -88,5 +88,49 @@ test_expect_failure 'packed obs in alt ODB are repacked when local repo has pack
done
'
+test_expect_failure 'packed obs in alternate ODB kept pack are repacked' '
+ # swap the .keep so the commit object is in the pack with .keep
+ for p in alt_objects/pack/*.pack
+ do
+ base_name=$(basename $p .pack)
+ if test -f alt_objects/pack/$base_name.keep
+ then
+ rm alt_objects/pack/$base_name.keep
+ else
+ touch alt_objects/pack/$base_name.keep
+ fi
+ done
+ git repack -a -d &&
+ myidx=$(ls -1 .git/objects/pack/*.idx) &&
+ test -f "$myidx" &&
+ for p in alt_objects/pack/*.idx; do
+ git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
+ done | while read sha1 rest; do
+ if ! ( git verify-pack -v $myidx | grep "^$sha1" ); then
+ echo "Missing object in local pack: $sha1"
+ return 1
+ fi
+ done
+'
+
+test_expect_failure 'packed unreachable obs in alternate ODB are not loosened' '
+ rm -f alt_objects/pack/*.keep &&
+ mv .git/objects/pack/* alt_objects/pack/ &&
+ csha1=$(git rev-parse HEAD^{commit}) &&
+ git reset --hard HEAD^ &&
+ sleep 1 &&
+ git reflog expire --expire=now --expire-unreachable=now --all &&
+ # The pack-objects call on the next line is equivalent to
+ # git repack -A -d without the call to prune-packed
+ git pack-objects --honor-pack-keep --non-empty --all --reflog \
+ --unpack-unreachable </dev/null pack &&
+ rm -f .git/objects/pack/* &&
+ mv pack-* .git/objects/pack/ &&
+ test 0 = $(git verify-pack -v -- .git/objects/pack/*.idx |
+ egrep "^$csha1 " | sort | uniq | wc -l) &&
+ echo > .git/objects/info/alternates &&
+ test_must_fail git show $csha1
+'
+
test_done
--
1.6.2.16.geb16e
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox