* Re: Please support add -p with a new file, to add only part of the file
From: Jeff King @ 2012-01-10 18:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Jonathan Nieder, Josh Triplett, git,
Wincent Colaiuta
In-Reply-To: <7vpqer9znv.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 10:32:20AM -0800, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > A not-so-proper solution might of course start by looking at which files
> > are untracked, and only run the 'git add -N' immediately before patch
> > application.
>
> Isn't the real issue that we mistakenly gave an impression that "add -p"
> is the primary interface to the users, and forgot to tell them about the
> more general "add -i", which "add -p" is a small subset of?
Maybe it is just me, but I find "add -p" insanely useful, and the rest
of "add -i" to be worthless clutter. The "add -p" functionality is not
easily available anywhere else, but the rest of "add -i" can be easily
(and often more efficiently) mimicked using existing git commands.
> Even if you start with "add -N", there won't be individual "hunks" you can
> pick and choose from diffing emptiness and the whole new file, so you end
> up using "edit hunk" interface.
I don't think the main impetus for this is that people necessarily want
to pick and choose hunks from added files. I think it is simply a nice
workflow to do:
$ hack hack hack
$ git add -p ;# inspect and add changes
$ git commit
which is very similar to the traditional git workflow:
$ hack hack hack
$ git diff ;# inspect changes
$ git add foo ;# add changes
$ git commit
I find myself using "add -p" almost exclusively these days, as it
combines the two middle steps (and even though I usually am just hitting
"y" after inspection, when I _do_ want to make a change, I am right
there in the hunk selection loop already).
-Peff
^ permalink raw reply
* Re: [PATCH] gitignore: warn about pointless syntax
From: Jeff King @ 2012-01-10 18:51 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Junio C Hamano, git, trast
In-Reply-To: <alpine.LNX.2.01.1201100639340.11534@frira.zrqbmnf.qr>
On Tue, Jan 10, 2012 at 06:42:11AM +0100, Jan Engelhardt wrote:
> >You only have to implement proper backslash decoding, so I think it is
> >not as hard as reimplementing fnmatch:
> >[...]
> >
> >That being said, if this is such a commonly-requested feature
>
> Was it actually requested, or did you mean "commonly attempted use"?
Both. I meant in my sentence "if this is such a big problem that we need
to add a check for it, then surely it is something people would like to
be using". But if you peruse the list archives, you can find several
people mentioning that they would like it.
> As I see it, foo/**/*.o for example is equal to placing "*.o" in
> foo/.gitignore, so the feature is already implemented, just not
> through the syntax people falsely assume it is. And that is the
> reason for wanting to output a warning. If it was me, I'd even make
> it use error(), because that is the only way to educate people (and
> it works), but alas, some on the list might consider that too harsh.
Those features aren't exactly equivalent. Off the top of my head, I can
think of a few reasons to prefer using the top-level:
- you simply prefer it because it keeps your rules grouped in a more
logical way
- you don't control the sub-tree (e.g., it is brought in by sub-tree
merge, or you have an agreement with other devs not to touch things
in it. Also, I don't think .gitignores cross submodule boundaries
currently, but it is something that could happen eventually).
- you can write more complex rules with "**" that would otherwise
necessitate writing multiple rules split across directories
Don't get me wrong. I am not a huge proponent of "**", and I could
really care less if we implement it or not, and we have survived many
years without it. It just seems to me that if it's worth warning about,
it's worth implementing.
-Peff
^ permalink raw reply
* Re: [PATCH 4/8] revert: separate out parse errors logically
From: Jonathan Nieder @ 2012-01-10 19:03 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <1326212039-13806-5-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> For the first kind of error, it is insufficient to
> check if the buffer beings with a "pick" or "revert", otherwise the
> following insn sheet would be interpreted as having a malformed object
> name:
> pickle a1fe57~2
>
> In reality, the issue is that "pickle" is an unrecognized instruction.
> So, check that the buffer starts with ("pick " or "pick\t") and
> ("revert " or "revert\t").
Sorry, the above description just leaves me more confused than before.
What _actual impact_ does this patch have? And why do we want it?
And what could be the bad side effects? Everything else is just
irrelevant.
Before reading the above description, I thought this was just a code
cleanup. So either the description or my reading is completely
confused.
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Junio C Hamano @ 2012-01-10 19:23 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git, Henrik Grubbström, git-dev
In-Reply-To: <20120110182140.GB15273@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> IOW, our loop breaks out when attr_stack is NULL, but then we go on to
> assume that attr_stack is _not_ NULL. This isn't a bug, because it turns
> out that we always leave something in the attr_stack: the root
> gitattributes file (and the builtins). But it is slightly confusing to
> a reader because of the useless loop condition.
>
> I'm not sure if the right solution is to change the popping loop to:
>
> /* we will never run out of stack, because we always have the root */
> while (attr_stack->origin) {
> ...
Yeah, that makes sense, as that existing check "attr_stack &&" was a
misguided defensive coding, that was _not_ defensive at all as we didn't
do anything after we stop iterating from that loop and without checking
dereferenced attr_stack->origin, which was a simple bogosity.
>
> Or to be extra defensive and put:
>
> if (!attr_stack)
> die("BUG: we ran out of attr stack!?");
>
> after the loop, or to somehow handle the case of an empty attr stack
> below (which is hard to do, because it can't be triggered, so I have no
> idea what it would mean).
And this is even more so.
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Junio C Hamano @ 2012-01-10 19:25 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git, Henrik Grubbström, git-dev
In-Reply-To: <20120110180820.GA15273@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/attr.c b/attr.c
> index 76b079f..fa975da 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -582,7 +582,8 @@ static void prepare_attr_stack(const char *path)
>
> elem = attr_stack;
> if (namelen <= dirlen &&
> - !strncmp(elem->origin, path, namelen))
> + !strncmp(elem->origin, path, namelen) &&
> + (!namelen || path[namelen] == '/'))
> break;
Thanks for the fix; I was looking at path_matches() and wondering about
the same thing.
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Jeff King @ 2012-01-10 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlipf9xbe.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 11:23:01AM -0800, Junio C Hamano wrote:
> > I'm not sure if the right solution is to change the popping loop to:
> >
> > /* we will never run out of stack, because we always have the root */
> > while (attr_stack->origin) {
> > ...
>
> Yeah, that makes sense, as that existing check "attr_stack &&" was a
> misguided defensive coding, that was _not_ defensive at all as we didn't
> do anything after we stop iterating from that loop and without checking
> dereferenced attr_stack->origin, which was a simple bogosity.
>
> >
> > Or to be extra defensive and put:
> >
> > if (!attr_stack)
> > die("BUG: we ran out of attr stack!?");
> >
> > after the loop, or to somehow handle the case of an empty attr stack
> > below (which is hard to do, because it can't be triggered, so I have no
> > idea what it would mean).
>
> And this is even more so.
I wasn't clear: the second one is "even more so" making sense, or "even
more so" misguided defensive coding?
-Peff
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Jeff King @ 2012-01-10 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20120110192810.GA16018@sigill.intra.peff.net>
On Tue, Jan 10, 2012 at 02:28:10PM -0500, Jeff King wrote:
> On Tue, Jan 10, 2012 at 11:23:01AM -0800, Junio C Hamano wrote:
>
> > > I'm not sure if the right solution is to change the popping loop to:
> > >
> > > /* we will never run out of stack, because we always have the root */
> > > while (attr_stack->origin) {
> > > ...
> >
> > Yeah, that makes sense, as that existing check "attr_stack &&" was a
> > misguided defensive coding, that was _not_ defensive at all as we didn't
> > do anything after we stop iterating from that loop and without checking
> > dereferenced attr_stack->origin, which was a simple bogosity.
> >
> > >
> > > Or to be extra defensive and put:
> > >
> > > if (!attr_stack)
> > > die("BUG: we ran out of attr stack!?");
> > >
> > > after the loop, or to somehow handle the case of an empty attr stack
> > > below (which is hard to do, because it can't be triggered, so I have no
> > > idea what it would mean).
> >
> > And this is even more so.
>
> I wasn't clear: the second one is "even more so" making sense, or "even
> more so" misguided defensive coding?
If the latter, then I think we want this:
-- >8 --
Subject: [PATCH] attr: drop misguided defensive coding
In prepare_attr_stack, we pop the old elements of the stack
(which were left from a previous lookup and may or may not
be useful to us). Our loop to do so checks that we never
reach the top of the stack. However, the code immediately
afterwards will segfault if we did actually reach the top of
the stack.
Fortunately, this is not an actual bug, since we will never
pop all of the stack elements (we will always keep the root
gitattributes, as well as the builtin ones). So the extra
check in the loop condition simply clutters the code and
makes the intent less clear. Let's get rid of it.
Signed-off-by: Jeff King <peff@peff.net>
---
attr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index fa975da..cf8f2bc 100644
--- a/attr.c
+++ b/attr.c
@@ -577,7 +577,7 @@ static void prepare_attr_stack(const char *path)
* Pop the ones from directories that are not the prefix of
* the path we are checking.
*/
- while (attr_stack && attr_stack->origin) {
+ while (attr_stack->origin) {
int namelen = strlen(attr_stack->origin);
elem = attr_stack;
--
1.7.9.rc0.33.gd3c17
^ permalink raw reply related
* Re: Please support add -p with a new file, to add only part of the file
From: Junio C Hamano @ 2012-01-10 19:33 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, Jonathan Nieder, Josh Triplett, git,
Wincent Colaiuta
In-Reply-To: <20120110183833.GA15787@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Even if you start with "add -N", there won't be individual "hunks" you can
>> pick and choose from diffing emptiness and the whole new file, so you end
>> up using "edit hunk" interface.
>
> I don't think the main impetus for this is that people necessarily want
> to pick and choose hunks from added files.
Well, read the subject of your e-mail and tell me what it says ;-)
And that is why I was contrasting an imaginary workflow to use the
existing "add -p" with requested "allow it to be used with new files" with
what somebody may "emulate" without help from "add -p" machinery, which
is:
$ cp newfile.c newfile.c-saved
$ edit newfile.c ;# delete all the things you do not want for now
$ git add newfile.c
$ mv newfile.c-saved newfile.c
I just had to point the above out, even though I agree with the use case
you shown below for final verification. They are quite different topic, as
"git diff" won't be very useful for 'inspect changes' step in the "new
file" case to begin with.
> $ hack hack hack
> $ git add -p ;# inspect and add changes
> $ git commit
>
> which is very similar to the traditional git workflow:
>
> $ hack hack hack
> $ git diff ;# inspect changes
> $ git add foo ;# add changes
> $ git commit
>
> I find myself using "add -p" almost exclusively these days, as it
> combines the two middle steps (and even though I usually am just hitting
> "y" after inspection, when I _do_ want to make a change, I am right
> there in the hunk selection loop already).
^ permalink raw reply
* Re: Please support add -p with a new file, to add only part of the file
From: Jeff King @ 2012-01-10 19:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Jonathan Nieder, Josh Triplett, git,
Wincent Colaiuta
In-Reply-To: <7vd3ar9wto.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> Even if you start with "add -N", there won't be individual "hunks" you can
> >> pick and choose from diffing emptiness and the whole new file, so you end
> >> up using "edit hunk" interface.
> >
> > I don't think the main impetus for this is that people necessarily want
> > to pick and choose hunks from added files.
>
> Well, read the subject of your e-mail and tell me what it says ;-)
Heh. Oops.
Yes, I agree that "add -p" is not especially useful for that case, and
the workflow I was describing is very different[1].
Sorry for the noise.
-Peff
[1] For the record, I _do_ find myself using "git add -N" so that new
files can be part of my "git add -p" workflow. So that feature is
working as intended. It would save me a little bit of effort,
though, if I could tell git I also want to include untracked files
during the "-p" session, and dispense with the earlier "add -N".
I'd also find it useful to mark conflicts as resolved, but I think
we discussed that once before and you brought up some ugly corner
cases.
^ permalink raw reply
* Re: git svn dcommit sends to wrong branch
From: Thomas Rast @ 2012-01-10 19:43 UTC (permalink / raw)
To: git
In-Reply-To: <20120110161843.GC8196@victor>
Victor Engmark <victor.engmark@terreactive.ch> writes:
> Commands:
>
> git svn clone -s -r 1:HEAD http://svn/repo
> cd repo
> git commit [thrice, in master only]
Which git version is this? Before 1.6.5 (b186a261 to be precise)
git-svn pointed master at the branch where the last commit in SVN
happened, which is not necessarily trunk. After that it tries to point
it at trunk instead. You can find out, e.g., by saying 'git show' on
the fresh clone and looking at the git-svn-id line.
> git rebase --interactive HEAD~20 [i.e., started rebase in commits before
> the clone]
> [Merged two commits I had made *after* the clone]
> git commit ...
> git dcommit
>
> This created commits on
> <http://svn/repo/branches/branch_name>! Why? Is it because HEAD~20's
> git-svn-id <http://svn/repo/branches/branch_name@22481> is on that
> branch?
The rule is that the commits go to the branch named in the git-svn-id
line of the most recent first-parent ancestor of HEAD.
You can find the "base" commit in question with
git log -1 --first-parent --grep=^git-svn-id:
> And more importantly, how do I "replay" my commits on trunk?
You need to rebase the commits on trunk, and (very important) strip the
git-svn-id lines from their messages. If you only had a handful of
commits, your best bet is to use something like
git checkout -b newbranch
git rebase -i --onto svn/trunk svn/branch_name # or whatever git-svn named the remote branches
# edit all the 'pick' into 'reword'
# in every commit message editor that pops up, remove the git-svn-id line
gitk # make sure that you like the resulting history!
git svn dcommit
(If you have many commits, git-filter-branch can do the removal
automatically, but it's a bit of a loaded gun pointed at your foot.)
If your git-rebase is too old for 'reword', you can use 'edit' instead
and then, every time that git-rebase drops you into a command line, say
git commit --amend # and edit the commit message
git rebase --continue
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: leaky cherry-pick
From: Jeff King @ 2012-01-10 19:50 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Pete Wyckoff, git, Junio C Hamano,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CALkWK0nwE0c6qVvbauPrjmb3NX4NDeGSrvrC2ry2bjMeM4Hr0A@mail.gmail.com>
On Tue, Jan 10, 2012 at 10:58:45AM +0530, Ramkumar Ramachandra wrote:
> Interesting- I wonder where .gitattributes parsing code fits into all
> this. The purpose of bootstrap _attr_stack() is to populate
> attr_stack for its callers. Lots of memory allocation happening in
> handle_attr_line() -- that information is returned to
> bootstrap_attr_stack(). We have to keep backtracking until that
> information is provably useless and free it. Hm, convert_attrs() (in
> convert.c) is a common caller in both cases, but the populated
> attr_stack is local to attr.c; I wonder if this is the problem. If my
> hunch is right, it should be a trivial fix (caution: untested):
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
>
> diff --git a/attr.c b/attr.c
> index 76b079f..12e3824 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -745,6 +745,7 @@ int git_check_attr(const char *path, int num,
> struct git_attr_check *check)
> check[i].value = value;
> }
>
> + drop_attr_stack();
> return 0;
> }
I don't think this is right. The attr_stack is intentionally kept in
place after a lookup as a cache, because callers are very likely to
lookup nearby filenames. The first thing we do is pop unrelated parts of
the stack, keep the early bits, and then push any new needed
directories.
So if you do a lookup for "foo/bar/baz/file1", the stack afterwards would
be:
$GIT_DIR/info/attributes
foo/bar/baz/.gitattributes
foo/bar/.gitattributes
foo/.gitattributes
.gitattributes
[builtins]
If you then do a lookup for "foo/bar/baz/file2", it can use the exact
same stack without looking for or reparsing the attribute files. If you
then do a lookup for "foo/bar/bleep/file", it pops only the entry for
"foo/bar/baz/.gitattributes", and pushes only the entry for
"foo/bar/bleep/.gitattributes".
The calling code _could_ say "btw, I am done with attributes now, so
free the memory". But we don't bother, since it's a small amount of
memory, and other parts of the code may want it later.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Neal Kreitzinger @ 2012-01-10 19:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Clemens Buchacher, git, Junio C Hamano
In-Reply-To: <4F0AA7E2.9010200@alum.mit.edu>
On 1/9/2012 2:40 AM, Michael Haggerty wrote:
>
> Two comments:
>
> * The name "--fix" might be confusing because of its similarity to the
> "fixup" command that can be specified in the interactive instructions file.
>
> * I agree with you that "interactive rebase is frequently used not to
> rebase history, but to manipulate recent commits". In fact, I use
> interactive rebase *only* for manipulating recent commits and
> non-interactive rebase *only* for changing commits' ancestry. I think
> it is a good idea to make these two uses more distinct. For example, it
> makes me nervous that I might mis-type the<upstream> parameter when I
> am trying to touch up commits and end up inadvertently rebasing the
> commits onto a new parent.
>
He could all it --touchup like you did above.
v/r,
neal
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Junio C Hamano @ 2012-01-10 20:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120110192810.GA16018@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 10, 2012 at 11:23:01AM -0800, Junio C Hamano wrote:
>
>> > I'm not sure if the right solution is to change the popping loop to:
>> >
>> > /* we will never run out of stack, because we always have the root */
>> > while (attr_stack->origin) {
>> > ...
>>
>> Yeah, that makes sense, as that existing check "attr_stack &&" was a
>> misguided defensive coding, that was _not_ defensive at all as we didn't
>> do anything after we stop iterating from that loop and without checking
>> dereferenced attr_stack->origin, which was a simple bogosity.
>>
>> >
>> > Or to be extra defensive and put:
>> >
>> > if (!attr_stack)
>> > die("BUG: we ran out of attr stack!?");
>> >
>> > after the loop, or to somehow handle the case of an empty attr stack
>> > below (which is hard to do, because it can't be triggered, so I have no
>> > idea what it would mean).
>>
>> And this is even more so.
>
> I wasn't clear: the second one is "even more so" making sense, or "even
> more so" misguided defensive coding?
Sorry for sending a half-baked response. The initial draft of my response
had just "that makes sense" and nothing else in the first paragraph.
If the original meant to be defensive, it should have had your "extra
defensive" die(), but it didn't.
But the condition to break out of that loop is either we hit an elem that
satisfy the condition (in which case that elem cannot be NULL) or we
successfully saw that attr_stack->origin is NULL (in which case attr_stack
couldn't have been NULL), so it is pointless to check the NULLness of
attr_stack itself. Assertion _before_ going into the while loop might make
sense, but if we look at what bootstrap_attr_stack() does, it should be
pretty obvious that that cannot happen.
An assert(attr_stack->origin) before we use it may make sense, though, in
order to make sure we do not mistakenly pop the root one and expose the
built-in ones whose origin are set to NULL.
diff --git a/attr.c b/attr.c
index ad7eb9c..4d3b61a 100644
--- a/attr.c
+++ b/attr.c
@@ -566,7 +567,9 @@ static void prepare_attr_stack(const char *path, int dirlen)
/*
* Pop the ones from directories that are not the prefix of
- * the path we are checking.
+ * the path we are checking. Break out of the loop when we see
+ * the root one (whose origin is an empty string "") or the builtin
+ * one (whose origin is NULL) without popping it.
*/
while (attr_stack->origin) {
int namelen = strlen(attr_stack->origin);
@@ -586,6 +589,13 @@ static void prepare_attr_stack(const char *path, int dirlen)
* Read from parent directories and push them down
*/
if (!is_bare_repository() || direction == GIT_ATTR_INDEX) {
+ /*
+ * bootstrap_attr_stack() should have added, and the
+ * above loop should have stopped before popping, the
+ * root element whose attr_stack->origin is set to an
+ * empty string.
+ */
+ assert(attr_stack->origin);
while (1) {
char *cp;
^ permalink raw reply related
* rsync a *bunch* of git repos
From: Jason @ 2012-01-10 21:15 UTC (permalink / raw)
To: git
All,
I have a home directory with a lot of git repos in it. Possibly over a
hundred. This is a good thing. :-) However, I'm in the process of
changing OS's and need to move my home directory out of my root
partition into its own partition.
The nuts and bolts of this aren't difficult, the problem is I don't have
a complete understanding of how git stores data. I've heard in the
past that it uses a lot of hardlinks and softlinks. I need to make
sure, that once I transfer the data, and reboot the machine with the new
partition mounted under /home, that all my git repos will be okay.
Going through the git repos one by one would be long and prone to
errors, so I'm looking at alternatives. Does this look ok?
## From single user mode, or live cd
$ su -
# mkfs.ext4 /dev/sda3
# mount /dev/sda3 /mnt/home
# rsync --progress -avu /home/ /mnt/home/
# umount /mnt/home
# mv /home /home.orig
# mkdir /home
### Sanity check?
# mount /dev/sda3 /home
# rsync -avun /home.orig/ /home/
That'll check that rsync thinks things are ok, but what about git? Is
there a git sanity check I could run to detect that three hardlinks
still point to the same inode?
One alternative may be to boot to a live CD, delete everything from the
root partition except /home, then mv /home/* -> / . Basically, use my
current root partition as the new /home partition.
thx,
Jason.
^ permalink raw reply
* [BUG] git archive broken in 1.7.8.1
From: Albert Astals Cid @ 2012-01-10 21:18 UTC (permalink / raw)
To: git
CC me on answers since i'm not subscribed to the list
Hi, one of our [KDE] anongit servers was updated to 1.7.8.1 and not the syntax
git archive --remote=git://anongit.kde.org/repo.git HEAD:path
does not seem to return a valid tar archive anymore when it did work
previously. In fact the man page of my version has that syntax in one of the
examples.
Is that a regression or should have never it worked and the current behaviour
is the correct one?
Albert
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Seth Robertson @ 2012-01-10 21:24 UTC (permalink / raw)
To: Jason; +Cc: git
In-Reply-To: <20120110211548.GD10255@titan.lakedaemon.net>
In message <20120110211548.GD10255@titan.lakedaemon.net>, Jason writes:
The nuts and bolts of this aren't difficult, the problem is I don't have
a complete understanding of how git stores data. I've heard in the
past that it uses a lot of hardlinks and softlinks. I need to make
sure, that once I transfer the data, and reboot the machine with the new
partition mounted under /home, that all my git repos will be okay.
Under most circumstances, git will do the right thing. Only if you
use specific flags on clone (like --shared or --reference) might
something go wrong, and as the manual page explains, you can use
git-repack to undo these.
The real solution is, after you rsync, to:
for f in */.git; do (cd $f; git fsck >&/dev/null || echo "$f is BAD!!"); done
If you get no output, you should be golden. If you get output, check
to make sure the repo you are copying from is good as well.
-Seth Robertson
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Carlos Martín Nieto @ 2012-01-10 21:33 UTC (permalink / raw)
To: Albert Astals Cid; +Cc: git
In-Reply-To: <5142795.2dTmMhVRTP@xps>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
On Tue, Jan 10, 2012 at 10:18:41PM +0100, Albert Astals Cid wrote:
> CC me on answers since i'm not subscribed to the list
>
> Hi, one of our [KDE] anongit servers was updated to 1.7.8.1 and not the syntax
>
> git archive --remote=git://anongit.kde.org/repo.git HEAD:path
This syntax is no longer allowed due to some security tightening. Use
the alternate syntax
git archive --remote=git://anongit.kde.org/repo.git HEAD -- path
>
> does not seem to return a valid tar archive anymore when it did work
> previously. In fact the man page of my version has that syntax in one of the
> examples.
That sounds like a documentation bug.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Philip Oakley @ 2012-01-10 22:00 UTC (permalink / raw)
To: Jason, Seth Robertson; +Cc: git
In-Reply-To: <201201102124.q0ALOowL026941@no.baka.org>
From: "Seth Robertson" <in-gitvger@baka.org> Sent: Tuesday, January 10, 2012
9:24 PM
> In message <20120110211548.GD10255@titan.lakedaemon.net>, Jason writes:
>
> The nuts and bolts of this aren't difficult, the problem is I don't
> have
> a complete understanding of how git stores data. I've heard in the
> past that it uses a lot of hardlinks and softlinks. I need to make
> sure, that once I transfer the data, and reboot the machine with the
> new
> partition mounted under /home, that all my git repos will be okay.
>
> Under most circumstances, git will do the right thing. Only if you
> use specific flags on clone (like --shared or --reference) might
> something go wrong, and as the manual page explains, you can use
> git-repack to undo these.
I think there is an exception for certain git submodule setups with local
repos, where the gitdir link is hard coded to the absolute machine path.
There has been some discussion on the list recently about trying to cover
this case.
>
> The real solution is, after you rsync, to:
>
> for f in */.git; do (cd $f; git fsck >&/dev/null || echo "$f is BAD!!");
> done
>
> If you get no output, you should be golden. If you get output, check
> to make sure the repo you are copying from is good as well.
>
> -Seth Robertson
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Albert Astals Cid @ 2012-01-10 22:05 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <20120110213344.GI2714@centaur.lab.cmartin.tk>
El Dimarts, 10 de gener de 2012, a les 22:33:44, Carlos Martín Nieto va
escriure:
> On Tue, Jan 10, 2012 at 10:18:41PM +0100, Albert Astals Cid wrote:
> > CC me on answers since i'm not subscribed to the list
> >
> > Hi, one of our [KDE] anongit servers was updated to 1.7.8.1 and not the
> > syntax
> >
> > git archive --remote=git://anongit.kde.org/repo.git HEAD:path
>
> This syntax is no longer allowed due to some security tightening. Use
> the alternate syntax
>
> git archive --remote=git://anongit.kde.org/repo.git HEAD -- path
Unfortunately this producess a tarball with a different layout, e.g.
git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD:doc/en_US
gives me a tarball with the doc/en_US files in the root
git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD -- doc/en_US
gives me a tarball with the doc/en_US folders and then the files
Is there a way to keep the old behaviour or do we need to update our scripts?
Thanks for the fast answer!
Albert
>
> > does not seem to return a valid tar archive anymore when it did work
> > previously. In fact the man page of my version has that syntax in one of
> > the examples.
>
> That sounds like a documentation bug.
>
> cmn
^ permalink raw reply
* Re: Please support add -p with a new file, to add only part of the file
From: Josh Triplett @ 2012-01-10 22:29 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, Jonathan Nieder, git,
Wincent Colaiuta
In-Reply-To: <20120110193857.GA19665@sigill.intra.peff.net>
On Tue, Jan 10, 2012 at 02:38:57PM -0500, Jeff King wrote:
> On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > >> Even if you start with "add -N", there won't be individual "hunks" you can
> > >> pick and choose from diffing emptiness and the whole new file, so you end
> > >> up using "edit hunk" interface.
> > >
> > > I don't think the main impetus for this is that people necessarily want
> > > to pick and choose hunks from added files.
> >
> > Well, read the subject of your e-mail and tell me what it says ;-)
>
> Heh. Oops.
>
> Yes, I agree that "add -p" is not especially useful for that case, and
> the workflow I was describing is very different[1].
I've gotten used to editing diffs directly, and when I just want to
include subsets of a file on a chunk-by-chunk basis (for instance, one
new function but not another new function), I'd find it a lot easier and
less error-prone to "git add -p newfile" and edit a diff than to copy
the file aside, edit the original to delete pieces I don't want, add,
commit, and copy the file back.
Most importantly, I want to use "git add -p" because I know it'll
*never* modify my working copy, only the index. I find that a useful
safety property.
Apart from that, it also means I have less mental state to track
("remember to copy the original file back later").
- Josh Triplett
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Junio C Hamano @ 2012-01-10 22:30 UTC (permalink / raw)
To: Philip Oakley; +Cc: Jason, Seth Robertson, git
In-Reply-To: <25207BDC675840DEA94AA2B04D6783BD@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> I think there is an exception for certain git submodule setups with
> local repos, where the gitdir link is hard coded to the absolute
> machine path. There has been some discussion on the list recently
> about trying to cover this case.
But if you read the original post carefully, all repositories involved are
under /home before the transition, and they will move to the exact same
place under /home anyway, so I do not think the discussion you have in
mind would apply to this case.
The only thing that is needed after the move would be to run
git update-index --refresh
in all of the repositories, I think.
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Jeff King @ 2012-01-10 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h0z9ufu.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 12:25:09PM -0800, Junio C Hamano wrote:
> Sorry for sending a half-baked response. The initial draft of my response
> had just "that makes sense" and nothing else in the first paragraph.
>
> If the original meant to be defensive, it should have had your "extra
> defensive" die(), but it didn't.
> [...]
> diff --git a/attr.c b/attr.c
> index ad7eb9c..4d3b61a 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -566,7 +567,9 @@ static void prepare_attr_stack(const char *path, int dirlen)
>
> /*
> * Pop the ones from directories that are not the prefix of
> - * the path we are checking.
> + * the path we are checking. Break out of the loop when we see
> + * the root one (whose origin is an empty string "") or the builtin
> + * one (whose origin is NULL) without popping it.
> */
> while (attr_stack->origin) {
> int namelen = strlen(attr_stack->origin);
> @@ -586,6 +589,13 @@ static void prepare_attr_stack(const char *path, int dirlen)
> * Read from parent directories and push them down
> */
> if (!is_bare_repository() || direction == GIT_ATTR_INDEX) {
> + /*
> + * bootstrap_attr_stack() should have added, and the
> + * above loop should have stopped before popping, the
> + * root element whose attr_stack->origin is set to an
> + * empty string.
> + */
> + assert(attr_stack->origin);
> while (1) {
> char *cp;
Yeah, this version looks good to me (though I thought we usually spelled
assert as die("BUG: ...")).
-Peff
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Carlos Martín Nieto @ 2012-01-10 22:50 UTC (permalink / raw)
To: Albert Astals Cid; +Cc: git, peff
In-Reply-To: <1431498.0yPWNQLupF@xps>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
On Tue, Jan 10, 2012 at 11:05:45PM +0100, Albert Astals Cid wrote:
> El Dimarts, 10 de gener de 2012, a les 22:33:44, Carlos Martín Nieto va
> escriure:
> > On Tue, Jan 10, 2012 at 10:18:41PM +0100, Albert Astals Cid wrote:
> > > CC me on answers since i'm not subscribed to the list
> > >
> > > Hi, one of our [KDE] anongit servers was updated to 1.7.8.1 and not the
> > > syntax
> > >
> > > git archive --remote=git://anongit.kde.org/repo.git HEAD:path
> >
> > This syntax is no longer allowed due to some security tightening. Use
> > the alternate syntax
> >
> > git archive --remote=git://anongit.kde.org/repo.git HEAD -- path
>
> Unfortunately this producess a tarball with a different layout, e.g.
>
> git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD:doc/en_US
> gives me a tarball with the doc/en_US files in the root
>
> git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD -- doc/en_US
> gives me a tarball with the doc/en_US folders and then the files
>
> Is there a way to keep the old behaviour or do we need to update our scripts?
Not as far as I know. However, the commit that hardened the input
(ee27ca4a781844: archive: don't let remote clients get unreachable
commits, 2011-11-17) does state that HEAD:doc/en_US should be valid,
so it looks like it's actually a regression. As it's bedtime in my
timezone, I'm blaming Peff and I'll look into this if it hasn't been
fixed by the time I get to the office tomorrow.
>
> Thanks for the fast answer!
>
> Albert
>
> >
> > > does not seem to return a valid tar archive anymore when it did work
> > > previously. In fact the man page of my version has that syntax in one of
> > > the examples.
> >
> > That sounds like a documentation bug.
Notice that the syntax is for the local case, not for --remote.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Linus Torvalds @ 2012-01-10 22:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-kernel, Junio C Hamano, Git Mailing List
In-Reply-To: <20120110222711.GK7164@opensource.wolfsonmicro.com>
On Tue, Jan 10, 2012 at 2:27 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> Especially in the cases where the lack of the bug fix breaks the new
> code it sems sensible enough to want to do the merges so that the
> history includes things that actually work.
So I don't mind merges if they have a lear reason for existing.
This is actually one of my major gripes with the git UI, and one of
the few areas where I really think I screwed up: I made merging *too*
easy by default. I should have made it always start up an editor for a
merge message, the way it does for a commit - rather than just do a
trivial pointless merge without even asking the user for a reason for
the merge.
So looking at that almost two months of regulator history in
gitk d52739c62e00..269d430131b6
I would not have reacted badly at all if there were one or two of
those merges, and they actually had a reason associated with them.
Sadly, due to that git UI mess-up, that's harder to do than it should
be. Oh, it's easy enough with "git merge --no-commit" followed by just
"git commit", and then you get the normal git editor window.
So right now "git merge" (and "git pull") make it too easy to make
those meaningless merge commits. If instead of seven pointless merges
you had (say) had two merges that had messages about *why* they
weren't pointless, I'd be perfectly happy.
Addid junio and git to the cc just to bring up this issue of bad UI
once again. I realize it could break old scripts to start up an editor
window, but still..
Linus
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Allan Wind @ 2012-01-10 23:01 UTC (permalink / raw)
To: git
In-Reply-To: <1431498.0yPWNQLupF@xps>
On 2012-01-10 23:05:45, Albert Astals Cid wrote:
> Unfortunately this producess a tarball with a different layout, e.g.
>
> git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD:doc/en_US
> gives me a tarball with the doc/en_US files in the root
Meaning the files you have stored in git under doc/en_US are
dumped in the root directory of the tar? That does not sound
like desired behavior for the feature.
/Allan
--
Allan Wind
Life Integrity, LLC
<http://lifeintegrity.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox