* Re: fetch --no-tags with and w/o --all
From: Jeff King @ 2013-03-07 1:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Cristian Tibirna, git
In-Reply-To: <7vhakonirb.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 04:41:44PM -0800, Junio C Hamano wrote:
> > Or we could just pass them through. Looks like this was already fixed by
> > 8556646 (fetch --all: pass --tags/--no-tags through to each remote,
> > 2012-09-05), which is in v1.7.12.2 and higher.
>
> ;-) No wonder this looked somewhat familiar.
I still find it somewhat gross that we actually re-construct the
command-line from the parsed flag variables. It seems like it would be
easier to simply propagate the argv we got in the first place, and then
we would not have any chance of omitting a new option that is added
later.
Probably not worth worrying about now, though, as the fix is long since
shipped. The next person who is adding an option can look at doing that
refactoring. And it may be that there are some options we don't
propagate intentionally (I didn't look closely).
-Peff
^ permalink raw reply
* [gitweb] Removed reference to git.kernel.org
From: Fredrik Gustafsson @ 2013-03-07 1:23 UTC (permalink / raw)
To: gitster; +Cc: git, Fredrik Gustafsson
git.kernel.org no longer uses gitweb but has switched to cgit.
Info about this can be found on: https://www.kernel.org/pelican.html or
simply by looking at http://git.kernel.org . This is change since
2013-03-01.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
---
gitweb/README | 3 ---
1 fil ändrad, 3 borttagningar(-)
diff --git a/gitweb/README b/gitweb/README
index 6da4778..471dcfb 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -1,9 +1,6 @@
GIT web Interface
=================
-The one working on:
- http://git.kernel.org/
-
From the git version 1.4.0 gitweb is bundled with git.
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] p4merge: create a virtual base if none available
From: David Aguilar @ 2013-03-07 2:23 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git, Ciaran Jessup, Scott Chacon
In-Reply-To: <1362601978-16911-3-git-send-email-kevin@bracey.fi>
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey <kevin@bracey.fi> wrote:
> Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
>
> p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
>
> Commit 0a0ec7bd changed this to:
>
> p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
>
> to avoid the problem of being unable to save in some circumstances.
>
> Unfortunately this approach does not produce good results at all on
> differing inputs. P4Merge really regards the blank file as the base, and
> once you have just a couple of differences between the two branches you
> end up with one a massive full-file conflict. The diff is not readable,
> and you have to invoke "difftool MERGE_HEAD HEAD" manually to see a
> 2-way diff.
>
> The original form appears to have invoked special 2-way comparison
> behaviour that occurs only if the base filename is "" or equal to the
> left input. You get a good diff, and it does not auto-resolve in one
> direction or the other. (Normally if one branch equals the base, it
> would autoresolve to the other branch).
>
> But there appears to be no way of getting this 2-way behaviour and being
> able to reliably save. Having base=left appears to be triggering other
> assumptions. There are tricks the user can use to force the save icon
> on, but it's not intuitive.
>
> So we now follow a suggestion given in the original patch's discussion:
> generate a virtual base, consisting of the lines common to the two
> branches. It produces a much nicer 3-way diff view than either of the
> original forms, and than I suspect other mergetools are managing.
>
> Signed-off-by: Kevin Bracey <kevin@bracey.fi>
> ---
> git-mergetool--lib.sh | 14 ++++++++++++++
> mergetools/p4merge | 2 +-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index e338be5..5b60cf5 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -108,6 +108,20 @@ check_unchanged () {
> fi
> }
>
> +make_virtual_base() {
> + # Copied from git-merge-one-file.sh.
I think the reasoning behind these patches is good.
How do we feel about this duplication?
Should we make a common function in the git-sh-setup.sh,
or is it okay to have a slightly modified version of this
function in two places?
> + # This starts with $LOCAL, and uses git apply to
> + # remove lines that are not in $REMOTE.
> + cp -- "$LOCAL" "$BASE"
> + sz0=`wc -c <"$BASE"`
> + @@DIFF@@ -u -L"a/$BASE" -L"b/$BASE" "$BASE" "$REMOTE" | git apply --no-add
> + sz1=`wc -c <"$BASE"`
> +
> + # If we do not have enough common material, it is not
> + # worth trying two-file merge using common subsections.
> + expr $sz0 \< $sz1 \* 2 >/dev/null || : >"$BASE"
> +}
> +
> valid_tool () {
> setup_tool "$1" && return 0
> cmd=$(get_merge_tool_cmd "$1")
> diff --git a/mergetools/p4merge b/mergetools/p4merge
> index 46b3a5a..f0a893b 100644
> --- a/mergetools/p4merge
> +++ b/mergetools/p4merge
> @@ -21,7 +21,7 @@ diff_cmd () {
>
> merge_cmd () {
> touch "$BACKUP"
> - $base_present || >"$BASE"
> + $base_present || make_virtual_base
> "$merge_tool_path" "$BASE" "$REMOTE" "$LOCAL" "$MERGED"
> check_unchanged
> }
> --
> 1.8.2.rc2.5.g1a80410.dirty
>
--
David
^ permalink raw reply
* Re: [PATCH 2/2] p4merge: create a virtual base if none available
From: David Aguilar @ 2013-03-07 3:33 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git, Ciaran Jessup, Scott Chacon
In-Reply-To: <1362601978-16911-3-git-send-email-kevin@bracey.fi>
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey <kevin@bracey.fi> wrote:
> +make_virtual_base() {
> + # Copied from git-merge-one-file.sh.
> + # This starts with $LOCAL, and uses git apply to
> + # remove lines that are not in $REMOTE.
> + cp -- "$LOCAL" "$BASE"
> + sz0=`wc -c <"$BASE"`
> + @@DIFF@@ -u -L"a/$BASE" -L"b/$BASE" "$BASE" "$REMOTE" | git apply --no-add
> + sz1=`wc -c <"$BASE"`
> +
> + # If we do not have enough common material, it is not
> + # worth trying two-file merge using common subsections.
> + expr $sz0 \< $sz1 \* 2 >/dev/null || : >"$BASE"
> +}
This seems to be indented deeper then the other functions
(or gmail is whitespace damaging my view).
Please use one hard tab to indent here.
We prefer $(command) instead of `command`.
These should be adjusted.
Also, the "@@DIFF@@" string may not work here.
This is a template string that is replaced by the Makefile.
I don't think the tools in the mergetools/ directory go through
cmd_munge_script so this is not going to work as-is.
Can the same thing be accomplished using "git diff --no-index"
so that we do not need a dependency on an external "diff" command here?
I am not a regular p4merge user myself so I'll defer to others
on the cc: list for their thoughts. It does seem like a good idea, though.
--
David
^ permalink raw reply
* [PATCH 1/2] bundle: Fix "verify" output if history is complete
From: Lukas Fleischer @ 2013-03-07 0:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Lukas Fleischer
A more informative message for "complete" bundles was added in commit
8c3710fd. However, the prerequisites ref list is currently read *after*
we check if it equals zero, which means we never actually print the
newly introduced message.
Move the code that reads the prerequisites ref list before the check to
fix this.
Signed-off-by: Lukas Fleischer <git@cryptocrack.de>
---
I am not sure whether we should add a test case for such a simple "bug".
If you think we should, just let me know and I will add one.
bundle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bundle.c b/bundle.c
index 8d12816..65db53b 100644
--- a/bundle.c
+++ b/bundle.c
@@ -188,10 +188,10 @@ int verify_bundle(struct bundle_header *header, int verbose)
r->nr),
r->nr);
list_refs(r, 0, NULL);
+ r = &header->prerequisites;
if (!r->nr) {
printf_ln(_("The bundle records a complete history."));
} else {
- r = &header->prerequisites;
printf_ln(Q_("The bundle requires this ref",
"The bundle requires these %d refs",
r->nr),
--
1.8.2.rc2.352.g908df73
^ permalink raw reply related
* [PATCH 2/2] bundle: Add colons to list headings in "verify"
From: Lukas Fleischer @ 2013-03-07 0:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Lukas Fleischer
In-Reply-To: <1362617796-4120-1-git-send-email-git@cryptocrack.de>
These slightly improve the reading flow by making it obvious that a list
follows.
Signed-off-by: Lukas Fleischer <git@cryptocrack.de>
---
bundle.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65db53b..8cd8b4f 100644
--- a/bundle.c
+++ b/bundle.c
@@ -183,8 +183,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
struct ref_list *r;
r = &header->references;
- printf_ln(Q_("The bundle contains %d ref",
- "The bundle contains %d refs",
+ printf_ln(Q_("The bundle contains %d ref:",
+ "The bundle contains %d refs:",
r->nr),
r->nr);
list_refs(r, 0, NULL);
@@ -192,8 +192,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
if (!r->nr) {
printf_ln(_("The bundle records a complete history."));
} else {
- printf_ln(Q_("The bundle requires this ref",
- "The bundle requires these %d refs",
+ printf_ln(Q_("The bundle requires this ref:",
+ "The bundle requires these %d refs:",
r->nr),
r->nr);
list_refs(r, 0, NULL);
--
1.8.2.rc2.352.g908df73
^ permalink raw reply related
* Re: [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool
From: Kevin Bracey @ 2013-03-07 6:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, David Aguilar, Ciaran Jessup, Scott Chacon
In-Reply-To: <7vlia0nj0i.fsf@alter.siamese.dyndns.org>
On 07/03/2013 02:36, Junio C Hamano wrote:
> Kevin Bracey <kevin@bracey.fi> writes:
>
>> Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
>> the incoming branch is now in the left-hand, blue triangle pane, and the
>> current branch is in the right-hand, green circle pane.
> Given that the ordering of the three variants has been the way it is
> since the very initial version by Scott, I'll sit on this patch
> until hearing from those Cc'ed (who presumably do use p4merge,
> unlike I who don't) that it is a good change.
>
I agree that this is the controversial patch of the two. It's going to
chuck away 3-4 years of what Git users are used to, albeit in favour of
a decade of what Perforce users are used to. And it also makes it
inconsistent with all the other mergetools (at least assuming their
display matches their command line).
I checked for any historical discussion from when this was added about
the order, and there was none. So I'm assuming it was just done to match
the other tools, maybe not realising P4Merge's "theirs/ours" convention.
There was no explicit recognition at the time that they were breaking
the Perforce convention, or that the order had an effect.
I've used both Git and Perforce for quite a while, but have only just
started using P4Merge with Git. It seemed weirdly off and unintuitive to
me at first, until I suddenly realised that it was just backwards. I
would have settled for just having to get used to driving on the other
side of the road, and matching other mergetools, until I realised that
it effectively broke display of common changes. That's a problem.
On consistency, personally, I think there's an argument for reversing
all the mergetools to match this way, as I find this orientation more
intuitively aligns with difftool. But I'm not bold enough to suggest
that. Yet.
Kevin
^ permalink raw reply
* Re: feature suggestion: improve rerere
From: Johannes Sixt @ 2013-03-07 7:05 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, kernel
In-Reply-To: <20130306144225.GB15375@pengutronix.de>
Am 3/6/2013 15:42, schrieb Uwe Kleine-König:
> On Wed, Mar 06, 2013 at 02:24:18PM +0100, Johannes Sixt wrote:
>> Am 3/6/2013 11:16, schrieb Uwe Kleine-König:
>>> ++<<<<<<< ours
>>> +ssize_t xread(int fd, void *buf, size_t count)
>>> +{
>>> + ssize_t ret, done = 0;
>>> +
>>> +retry:
>>> + ret = read(fd, buf + done, count - done);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + done += ret;
>>> +
>>> + if (ret == 0 /* EOF */ || done == count)
>>> + return done;
>>> + else
>>> + goto retry;
>>> +}
>>> +
>>> ++||||||| base
>>> ++=======
>>> + #include "common.h"
>>> +
>>> ++>>>>>>> theirs
>>> int main(int argc,char *argv[])
>>> {
>>> int fd, val, ret, size, wrote, len;
>>>
>>> This is the same conflict as the first one, just with ours and theirs
>>> exchanged. So my suggestion is to make rerere use the resolution
>>> recorded for the first conflict here.
>>>
>>> Sounds sensible?
>>
>> Of course, and rerere already does it. But only when you use git's default
>> conflict markers rather than diff3 style markers that have this extra
>> ||||| line.
> I only did git checkout --conflict=diff3 after the merge conflict
> happend. So I cannot confirm that git already does it.
>
> So here is a reproduction receipe:
>
> git clone git://git.infradead.org/mtd-utils.git
> cd mtd-utils
> git checkout ca39eb1
> wget -O patch1 http://article.gmane.org/gmane.linux.drivers.mtd/45779/raw
> wget -O patch2 http://article.gmane.org/gmane.linux.drivers.mtd/45591/raw
At least patch2 has incorret index information; it does not apply with am
-3. I generated a working version with format-patch after applying it
directly on top of ca39eb1.
> for p in patch1 patch2; do perl -p -i -e 'print "From tralala Mon Sep 17 00:00:00 2001\n" if $. == 1' $p; done
Do you have rerere enabled at this point?
git config rerere.enabled true
> git am patch1
> git am -3 patch2 # first merge conflict
> perl -n -i -e 's/=======//; print unless /^[<>]{7} /;' flash_otp_write.c # resolve
> git add flash_otp_write.c
> git am --resolved
> git rebase -i ca39eb1 # swap order of the two patches
>
> results in
>
> $ git ls-files -u
> 100644 f360a3e025deaf7acfb7b20c9fad90f498ae4430 1 flash_otp_write.c
> 100644 d407ebbf400e630dc00ee004ecb44be8af51b25d 2 flash_otp_write.c
> 100644 31b963e2d6cf0016ca542529886e1ee71a22664e 3 flash_otp_write.c
Same here.
>
> and resolving yields:
>
> $ git ls-files -s flash_otp_write.c
> 100644 648e0422d21c0ffa7621f82b86c02a065e488293 0 flash_otp_write.c
OK.
>
> Then
> git rebase --continue
>
> gives the 2nd rebase conflict:
>
> $ git ls-files -u
> 100644 d407ebbf400e630dc00ee004ecb44be8af51b25d 1 flash_otp_write.c
> 100644 648e0422d21c0ffa7621f82b86c02a065e488293 2 flash_otp_write.c
> 100644 f360a3e025deaf7acfb7b20c9fad90f498ae4430 3 flash_otp_write.c
Same here.
>
> Now knowing from the previous resolution that with base=f360a3e0
> (= origin + patch1) merging
>
> d407ebbf (= origin) and
> 31b963e2 (= origin + patch1 + patch2)
>
> gives 648e0422 (origin + patch2),
> git could know that with base=d407ebbf (origin) merging 648e0422 (origin
> + patch1) and f360a3e0 (origin + patch1) gives 31b963e2 (origin + patch1
> + patch2) again.
For me, it works as expected, i.e., I get the conflict resolved by rerere.
>
> And git doesn't prepare 31b963e2 in flash_otp_write.c for me.
>
> @Johannes, do you have some non-standard setting, or can you reproduce?
Perhaps:
$ git config --global -l | grep rerere
rerere.enabled=true
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool
From: Junio C Hamano @ 2013-03-07 7:23 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git, David Aguilar, Ciaran Jessup, Scott Chacon
In-Reply-To: <513830AD.10302@bracey.fi>
Kevin Bracey <kevin@bracey.fi> writes:
> I agree that this is the controversial patch of the two. It's going to
> chuck away 3-4 years of what Git users are used to, albeit in favour
> of a decade of what Perforce users are used to. And it also makes it
> inconsistent with all the other mergetools (at least assuming their
> display matches their command line).
If p4merge GUI labels one side clearly as "theirs" and the other
"ours", and the way we feed the inputs to it makes the side that is
actually "ours" appear in p4merge GUI labelled as "theirs", then I
do not think backward compatibility argument does not hold water. It
is just correcting a longstanding 3-4 year old bug in a tool that
nobody noticed.
For people who are very used to the way p4merge shows the merged
contents by theirs-base-yours order in side-by-side view, I do not
think it is unreasonable to introduce the "mergetool.$name.reverse"
configuration variable and teach the mergetool frontend to pay
attention to it. That will allow them to see their merge in reverse
order even when they are using a backend other than p4merge.
With such a mechanism in place, by default, we can just declare that
mergetool.p4merge.reverse is "true" when unset, while making
mergetool.$name.reverse for all the other tools default to "false".
People who are already used to the way our p4merge integration works
can set mergetool.p4merge.reverse to "false" explicitly to retain
the historical behaviour that you are declaring "buggy" with such a
change.
How does that sound? David?
^ permalink raw reply
* Re: [PATCH 2/2] p4merge: create a virtual base if none available
From: Junio C Hamano @ 2013-03-07 7:25 UTC (permalink / raw)
To: David Aguilar; +Cc: Kevin Bracey, git, Ciaran Jessup, Scott Chacon
In-Reply-To: <CAJDDKr6+VRnc-HK52woHHLtAqXau=76Gc+Ag=keiMGffuco64A@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> How do we feel about this duplication?
> Should we make a common function in the git-sh-setup.sh,
> or is it okay to have a slightly modified version of this
> function in two places?
It probably is a good idea to have it in one place. That would also
solve the @@DIFF@@ replacement issue you noticed at the same time.
^ permalink raw reply
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Jeff King @ 2013-03-07 8:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <7vmwugp637.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 01:32:28PM -0800, Junio C Hamano wrote:
> > We show "both sides added, either identically or differently" as
> > noteworthy events, but the patched code pushes "both sides added
> > identically" case outside the conflicting hunk, as if what was added
> > relative to the common ancestor version (in Uwe's case, is it 1-14
> > that is common, or just 10-14?) is not worth looking at when
> > considering what the right resolution is. If it is not worth
> > looking at what was in the original for the conflicting part, why
> > would we be even using diff3 mode in the first place?
>
> I vaguely recall we did this "clip to eager" as an explicit bugfix
> at 83133740d9c8 (xmerge.c: "diff3 -m" style clips merge reduction
> level to EAGER or less, 2008-08-29). The list archive around that
> time may give us more contexts.
Thanks for the pointer. The relevant threads are:
http://article.gmane.org/gmane.comp.version-control.git/94228
and
http://thread.gmane.org/gmane.comp.version-control.git/94339
There is not much discussion beyond what ended up in 8313374; both Linus
and Dscho question whether level and output format are orthogonal, but
seem to accept the explanation you give in the commit message.
Having read that commit and the surrounding thread, I think I stand by
my argument that "zdiff3" is a useful tool to have, as long as the user
understands what the hunks mean. It should never replace diff3, but I
think it makes sense as a separate format.
I was also curious whether it would the diff3/zealous combination would
trigger any weird corner cases. In particular, I wanted to know how the
example you gave in that commit of:
postimage#1: 1234ABCDE789
| /
| /
preimage: 123456789
| \
| \
postimage#2: 1234AXCYE789
would react with diff3 (this is not the original example, but one with
an extra "C" in the middle of postimage#2, which could in theory be
presented as split hunks). However, it seems that we do not do such hunk
splitting at all, neither for diff3 nor for the "merge" representation.
-Peff
^ permalink raw reply
* Re: [PATCH] git p4: chdir resolves symlinks only for relative paths
From: Miklós Fazekas @ 2013-03-07 8:36 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Gary Gibbons
In-Reply-To: <20130203230803.GA25555@padd.com>
Sorry for the late turnaround here is an improved version. Now chdir
has an optional argument client_path, if it's true then we don't do
os.getcwd. I think that my first patch is also valid too - when the
path is absolute no need for getcwd no matter what is the context,
when it's relative we have to use os.getcwd() no matter of the
context.
---
If p4 client is configured to /p/foo which is a symlink:
/p/foo -> /vol/barvol/projects/foo. Then resolving the
symlink will confuse p4:
"Path /vol/barvol/projects/foo/... is not under client root
/p/foo". While AltRoots in p4 client specification can be
used as a workaround on p4 side, git-p4 should not resolve
symlinks in client paths.
chdir(dir) uses os.getcwd() after os.chdir(dir) to resolve
relative paths, but as a sideeffect it resolves symlinks
too. Now for client paths we don't call os.getcwd().
Signed-off-by: Miklós Fazekas <mfazekas@szemafor.com>
---
git-p4.py | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 0682e61..2bd8cc2 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -68,12 +68,17 @@ def p4_build_cmd(cmd):
real_cmd += cmd
return real_cmd
-def chdir(dir):
+def chdir(dir,client_path=False):
# P4 uses the PWD environment variable rather than getcwd(). Since we're
# not using the shell, we have to set it ourselves. This path could
# be relative, so go there first, then figure out where we ended up.
+ # os.getcwd() will resolve symlinks, so we should avoid it for
+ # client_paths.
os.chdir(dir)
- os.environ['PWD'] = os.getcwd()
+ if client_path:
+ os.environ['PWD'] = dir
+ else:
+ os.environ['PWD'] = os.getcwd()
def die(msg):
if verbose:
@@ -1554,7 +1559,7 @@ class P4Submit(Command, P4UserMap):
new_client_dir = True
os.makedirs(self.clientPath)
- chdir(self.clientPath)
+ chdir(self.clientPath,client_path=True)
if self.dry_run:
print "Would synchronize p4 checkout in %s" % self.clientPath
else:
--
1.7.10.2 (Apple Git-33)
On Mon, Feb 4, 2013 at 12:08 AM, Pete Wyckoff <pw@padd.com> wrote:
> mfazekas@szemafor.com wrote on Tue, 29 Jan 2013 09:37 +0100:
>> If a p4 client is configured to /p/foo which is a symlink
>> to /vol/bar/projects/foo, then resolving symlink, which
>> is done by git-p4's chdir will confuse p4: "Path
>> /vol/bar/projects/foo/... is not under client root /p/foo"
>> While AltRoots in p4 client specification can be used as a
>> workaround on p4 side, git-p4 should not resolve symlinks
>> in client paths.
>> chdir(dir) uses os.getcwd() after os.chdir(dir) to resolve
>> relative paths, but as a side effect it resolves symlinks
>> too. Now it checks if the dir is relative before resolving.
>>
>> Signed-off-by: Miklós Fazekas <mfazekas@szemafor.com>
>> ---
>> git-p4.py | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/git-p4.py b/git-p4.py
>> index 2da5649..5d74649 100755
>> --- a/git-p4.py
>> +++ b/git-p4.py
>> @@ -64,7 +64,10 @@ def chdir(dir):
>> # not using the shell, we have to set it ourselves. This path could
>> # be relative, so go there first, then figure out where we ended up.
>> os.chdir(dir)
>> - os.environ['PWD'] = os.getcwd()
>> + if os.path.isabs(dir):
>> + os.environ['PWD'] = dir
>> + else:
>> + os.environ['PWD'] = os.getcwd()
>>
>> def die(msg):
>> if verbose:
>
> Thanks, this is indeed a bug and I have reproduced it with a test
> case. Your patch works, but I think it would be better to
> separate the callers of chdir(): those that know they are
> cd-ing to a path from a p4 client, and everybody else. The former
> should not use os.getcwd(), as you show.
>
> I'll whip something up soon, unless you beat me to it.
>
> -- Pete
^ permalink raw reply related
* Re: git-scm.com/book/ru -- incorrect "next" link containing a question mark
From: Konstantin Khomoutov @ 2013-03-07 8:47 UTC (permalink / raw)
To: git-users; +Cc: Aleksey Rozhkov, git
In-Reply-To: <5fe58162-33ed-48c2-a095-e98a355ed4f6@googlegroups.com>
On Thu, 7 Mar 2013 00:01:31 -0800 (PST)
Aleksey Rozhkov <ekkertan@gmail.com> wrote:
> The page http://git-scm.com/book/ru/
> Введение-Первоначальная-настройка-Git contains incorrect link "next"
> Now this link to the page
> http://git-scm.com/book/ru/Введение-Как-получить-помощь? , but this
> page does not exist
I would say "?" is just interpreted as a request part of the URL.
Indeed, the page source contains:
<a href="/book/ru/Введение-Установка-Git">prev</a> | <a
href="/book/ru/Введение-Как-получить-помощь?">next</a>
so the question mark is really included verbatim.
> So, correct link is
> http://git-scm.com/book/ru/Введение-Как-получить-помощь%3F
Good point, thanks. I Cc'ed the main Git list and made the message
title a bit more clear.
To the Pro Git book maintainer: is it possible to somehow fix the HTML
generation script to URL-encode any special characters if they're to
appear in an URL?
^ permalink raw reply
* Re: What I want rebase to do
From: Thomas Rast @ 2013-03-07 8:48 UTC (permalink / raw)
To: Dale R. Worley; +Cc: Junio C Hamano, git
In-Reply-To: <201303061855.r26ItKtM018797@freeze.ariadne.com>
worley@alum.mit.edu (Dale R. Worley) writes:
[...snip...]
Isn't that just a very long-winded way of restating what Junio said
earlier:
> > It was suggested to make it apply the first-parent diff and record
> > the result, I think. If that were an acceptable approach (I didn't
> > think about it through myself, though), that would automatically
> > cover the evil-merge case as well.
You can fake that with something like
git rev-list --first-parent --reverse RANGE_TO_REBASE |
while read rev; do
if git rev-parse $rev^2 >/dev/null 2>&1; then
git cherry-pick -n -m1 $rev
git rev-parse $rev^2 >.git/MERGE_HEAD
git commit -C$rev
else
git cherry-pick $rev
fi
done
Only tested very lightly. Dealing with octopii, conflicts and actually
preserving the commit's attributes is left as an exercise to the
reader[1].
I still think that the _right_ solution is first redoing the merge on
its original parents and then seeing how the actual merge differs from
that. --preserve-merges has bigger issues though, like Junio said.
Perhaps a new option to git-rebase could trigger the above behavior for
merges, who knows. (It could be called --first-parent.)
[1] If you don't get the sarcasm: that would amount to reinventing
large parts of git-rebase.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] git p4: chdir resolves symlinks only for relative paths
From: John Keeping @ 2013-03-07 9:13 UTC (permalink / raw)
To: Miklós Fazekas; +Cc: Pete Wyckoff, git, Gary Gibbons
In-Reply-To: <CAAMmcSQszVbDERd964VLu1d4UG7SihC+Pn99D0gPvG7HAZp2UQ@mail.gmail.com>
On Thu, Mar 07, 2013 at 09:36:06AM +0100, Miklós Fazekas wrote:
> Sorry for the late turnaround here is an improved version. Now chdir
> has an optional argument client_path, if it's true then we don't do
> os.getcwd. I think that my first patch is also valid too - when the
> path is absolute no need for getcwd no matter what is the context,
> when it's relative we have to use os.getcwd() no matter of the
> context.
>
> ---
> If p4 client is configured to /p/foo which is a symlink:
> /p/foo -> /vol/barvol/projects/foo. Then resolving the
> symlink will confuse p4:
> "Path /vol/barvol/projects/foo/... is not under client root
> /p/foo". While AltRoots in p4 client specification can be
> used as a workaround on p4 side, git-p4 should not resolve
> symlinks in client paths.
> chdir(dir) uses os.getcwd() after os.chdir(dir) to resolve
> relative paths, but as a sideeffect it resolves symlinks
> too. Now for client paths we don't call os.getcwd().
>
> Signed-off-by: Miklós Fazekas <mfazekas@szemafor.com>
> ---
> git-p4.py | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 0682e61..2bd8cc2 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -68,12 +68,17 @@ def p4_build_cmd(cmd):
> real_cmd += cmd
> return real_cmd
>
> -def chdir(dir):
> +def chdir(dir,client_path=False):
Style (space after comma):
def chdir(dir, client_path=False):
> # P4 uses the PWD environment variable rather than getcwd(). Since we're
> # not using the shell, we have to set it ourselves. This path could
> # be relative, so go there first, then figure out where we ended up.
> + # os.getcwd() will resolve symlinks, so we should avoid it for
> + # client_paths.
> os.chdir(dir)
> - os.environ['PWD'] = os.getcwd()
> + if client_path:
> + os.environ['PWD'] = dir
> + else:
> + os.environ['PWD'] = os.getcwd()
Indentation seems to have gone a bit wrong here...
>
> def die(msg):
> if verbose:
> @@ -1554,7 +1559,7 @@ class P4Submit(Command, P4UserMap):
> new_client_dir = True
> os.makedirs(self.clientPath)
>
> - chdir(self.clientPath)
> + chdir(self.clientPath,client_path=True)
Again, there should be a space after the comma here.
> if self.dry_run:
> print "Would synchronize p4 checkout in %s" % self.clientPath
> else:
> --
> 1.7.10.2 (Apple Git-33)
^ permalink raw reply
* Re: Merging submodules - best merge-base
From: Daniel Bratell @ 2013-03-07 9:49 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
In-Reply-To: <20130306181156.GA4114@sandbox-ub>
Den 2013-03-06 19:12:05 skrev Heiko Voigt <hvoigt@hvoigt.net>:
> On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote:
>> I can phrase this in two ways and I'll start with the short way:
>>
>> Why does a merge of a git submodule use as merge-base the commit that
>> was
>> active in the merge-base of the parent repo, rather than the merge-base
>> of
>> the two commits that are being merged?
>>
>> The long question is:
>>
>> A submodule change can be merged, but only if the merge is a
>> "fast-forward" which I think is a fair demand, but currently it checks
>> if
>> it's a fast-forward from a commit that might not be very interesting
>> anymore.
>>
>> If two branches A and B split at a point when they used submodule commit
>> S1 (based on S), and both then switched to S2 (also based on S) and B
>> then
>> switched to S21, then it's today not possible to merge B into A, despite
>> S21 being a descendant of S2 and you get a conflict and this warning:
>>
>> warning: Failed to merge submodule S (commits don't follow merge-base)
>>
>> (attempt at ASCII gfx:
>>
>> Submodule tree:
>>
>> S ---- S1
>> \
>> \ - S2 -- S21
>>
>> Main tree:
>>
>> A' (uses S1) --- A (uses S2)
>> \
>> \ --- B' (uses S2) -- B (uses S21)
>>
>>
>> I would like it to end up as:
>>
>> A' (uses S1) --- A (uses S2) ------------ A+ (uses S21)
>> \ /
>> \ --- B' (uses S2) -- B (uses S21)- /
>>
>> And that should be legal since S21 is a descendant of S2.
>
> So to summarize what you are requesting: You want a submodule merge be
> two way in the view of the superproject and calculate the merge base
> in the submodule from the two commits that are going to be merged?
>
> It currently sounds logical but I have to think about it further and
> whether that might break other use cases.
Maybe both could be legal even. The current code can't be all wrong, and
this case also seems to be straightforward.
/Daniel
^ permalink raw reply
* Re: [PATCH 2/2] p4merge: create a virtual base if none available
From: Kevin Bracey @ 2013-03-07 6:28 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Ciaran Jessup, Scott Chacon
In-Reply-To: <CAJDDKr6+VRnc-HK52woHHLtAqXau=76Gc+Ag=keiMGffuco64A@mail.gmail.com>
On 07/03/2013 04:23, David Aguilar wrote:
> On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey <kevin@bracey.fi> wrote:
>> +make_virtual_base() {
>> + # Copied from git-merge-one-file.sh.
> I think the reasoning behind these patches is good.
>
> How do we feel about this duplication?
Bad.
> Should we make a common function in the git-sh-setup.sh,
> or is it okay to have a slightly modified version of this
> function in two places?
I'd prefer to have a common function, I just didn't know if there was
somewhere appropriate to place it, available from both files. And I'm
going to have to learn a bit more sh to get it right.
> Also, the "@@DIFF@@" string may not work here.
> This is a template string that is replaced by the Makefile.
It does work in git-mergetool--lib.sh, but not in mergetools/p4merge.
> We prefer $(command) instead of `command`.
> These should be adjusted.
>
> Can the same thing be accomplished using "git diff --no-index"
> so that we do not need a dependency on an external "diff" command here?
Do these comments still apply if it's a common function in
git-sh-setup.sh that git-one-merge-file.sh will use? I'm wary of
layering violations.
Kevin
^ permalink raw reply
* Re: What I want rebase to do
From: Johannes Sixt @ 2013-03-07 10:08 UTC (permalink / raw)
To: Thomas Rast; +Cc: Dale R. Worley, Junio C Hamano, git
In-Reply-To: <87r4jra942.fsf@pctrast.inf.ethz.ch>
Am 3/7/2013 9:48, schrieb Thomas Rast:
> worley@alum.mit.edu (Dale R. Worley) writes:
> [...snip...]
>
> Isn't that just a very long-winded way of restating what Junio said
> earlier:
>
>>> It was suggested to make it apply the first-parent diff and record
>>> the result, I think. If that were an acceptable approach (I didn't
>>> think about it through myself, though), that would automatically
>>> cover the evil-merge case as well.
>
> You can fake that with something like
>
> git rev-list --first-parent --reverse RANGE_TO_REBASE |
> while read rev; do
> if git rev-parse $rev^2 >/dev/null 2>&1; then
> git cherry-pick -n -m1 $rev
> git rev-parse $rev^2 >.git/MERGE_HEAD
> git commit -C$rev
> else
> git cherry-pick $rev
> fi
> done
>
> Only tested very lightly. Dealing with octopii, conflicts and actually
> preserving the commit's attributes is left as an exercise to the
> reader[1].
I proposed this long ago, but by modifying preserve-merges rather than
with a new option (--first-parent):
http://thread.gmane.org/gmane.comp.version-control.git/198125
It works very well. I'm using it frequently in the field.
-- Hannes
^ permalink raw reply
* Re: [PATCH] add: Clarify documentation of -A and -u
From: Greg Price @ 2013-03-07 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhakoqwri.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 09:10:57AM -0800, Junio C Hamano wrote:
> I do not know if mentioning what -A does in the description for -u
> (and vice versa) makes it easier to understand or more confusing
> (not rhetorical: I suspect some may find it easier and others not).
>
> But "and the default behaviour will..." here _is_ confusing. After
> reading this patch three times, I still cannot tell what "default"
> you are trying to describe. Is it "-u" without arguments? Is it
> "add" without "-u" nor "-A"? Is it something else???
I meant the behavior without -A or -u. This could be fixed directly
by s/the default behavior will/with neither -A nor -u we/. But we can
also keep revising -- there's definitely more room to make this
clearer! I suggest new versions at the bottom of this message.
I do think that it's important that the reader be able to see clearly
what the option does as a contrast with what the command does without
the option. Normally in a man page this is how the option is
described in the first place -- for example, the next entry in this
very man page says "Record *only* the fact that the path will be added
later", rather than "Record the fact that ..." These two descriptions
suffer from not doing that, so that it's not clear which parts of the
behavior they describe are just what 'add' does with no options and
which parts are actually due to the option.
> Whenever you see an incomprehensible technobabble followed by "That
> means", "In other words", etc., you (not limited to Greg-you but
> figuratively "everybody") should see if it makes it easier to read
> to remove everything up to that "That means" [...]
Seems like a reasonable heuristic.
> -u::
> --update::
> Update modified and/or removed paths in the index
> that match <pathspec> with the current state of the
> working tree files. No new path is added because
> this considers only the paths that are already in
> the index.
>
> -A::
> --all::
> Update the index to record the current state of the
> working tree files that match <pathspec>. Note that
> new paths will be added to the index, in addition to
> modified and/or removed paths.
These are good -- I especially like that they're shorter. I do think
they're still likely to be confusing. The lead sentences are hard to
tell apart from each other or one's mental model of what 'add' alone
does, though the contrasts that follow them help. I also think the
lead sentence for '--all' isn't really correct -- we update the index
not only for the working tree files that match <pathspec>, but also
where there is no working tree file, only an index entry. (So the
sentence actually describes what 'add' with neither option does.)
Maybe it's worth taking a step back. The overall taxonomy is
* 'add' alone considers matching filenames in the working tree
* 'add -u' considers matching filenames in the index
* 'add -A' considers matching filenames in both the index and the
working tree
and in each case we make the index match the working tree on those
files. Or, put another way,
* 'add' alone modifies and adds files
* 'add -u' modifies and removes files
* 'add -A' modifies, adds, and removes files
Here's a crack at making those distinctions clear. I've also tried to
make the descriptions as parallel as possible, as what they're saying
is very similar.
-u::
--update::
Update the index just where it already has an entry matching
<pathspec>. This removes as well as modifies index entries to
match the working tree, but adds no new files.
-A::
--all::
Update the index not only where the working tree has a file
matching <pathspec> but also where the index already has an
entry. This adds, modifies, and removes index entries to
match the working tree.
These are the shortest in the discussion so far, and I think they're
also the clearest.
Then follow both with the "If no <pathspec>" paragraph. I just
noticed that the paragraph actually needs a small modification to fit
'-A', too. New patch below.
Greg
From: Greg Price <price@mit.edu>
Date: Thu, 7 Mar 2013 02:08:21 -0800
Subject: [PATCH] add: Clarify documentation of -A and -u
The documentation of '-A' and '-u' is very confusing for someone who
doesn't already know what they do. Describe them with fewer words and
clearer parallelism to each other and to the behavior of plain 'add'.
Also mention the default <pathspec> for '-A' as well as '-u', because
it applies to both.
Signed-off-by: Greg Price <price@mit.edu>
---
Documentation/git-add.txt | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 388a225..b0944e5 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -100,12 +100,9 @@ apply to the index. See EDITING PATCHES below.
-u::
--update::
- Only match <pathspec> against already tracked files in
- the index rather than the working tree. That means that it
- will never stage new files, but that it will stage modified
- new contents of tracked files and that it will remove files
- from the index if the corresponding files in the working tree
- have been removed.
+ Update the index just where it already has an entry matching
+ <pathspec>. This removes as well as modifies index entries to
+ match the working tree, but adds no new files.
+
If no <pathspec> is given, the current version of Git defaults to
"."; in other words, update all tracked files in the current directory
@@ -114,10 +111,15 @@ of Git, hence the form without <pathspec> should not be used.
-A::
--all::
- Like `-u`, but match <pathspec> against files in the
- working tree in addition to the index. That means that it
- will find new files as well as staging modified content and
- removing files that are no longer in the working tree.
+ Update the index not only where the working tree has a file
+ matching <pathspec> but also where the index already has an
+ entry. This adds, modifies, and removes index entries to
+ match the working tree.
++
+If no <pathspec> is given, the current version of Git defaults to
+"."; in other words, update all files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <pathspec> should not be used.
-N::
--intent-to-add::
--
1.7.11.3
^ permalink raw reply related
* rebase: strange failures to apply patc 3-way
From: Max Horn @ 2013-03-07 10:16 UTC (permalink / raw)
To: git
Recently I have observed very strange failures in "git rebase" that cause it to fail to work automatically in situations where it should trivially be able to do so.
In case it matter, here's my setup: git 1.8.2.rc2.4.g7799588 (i.e. git.git master branch) on Mac OS X. The repos clone is on a HFS+ partition, not on a network volume. No gitattributes are being used. Regarding the origin of the repos (I hope it doesn't matter, but just in case): The repository in question used to be a CVS repository; it was decided to switch to Mercurial (not my decision ;-) and I performed the conversion; I first converted it to git using cvs2git (from the cvs2svn suite), then performed some history cleanup, and finally used "hg convert" to convert it to git. Recently, I have been accessing the repository from git via the gitifyhg tool <https://github.com/buchuki/gitifyhg>.
Anyway, several strange things just happened (and I had similar experiences in the past days and weeks, but that was using an older git, and I thought I was just doing something wrong).
Specifically, I wanted to rebase a branch with some experimental commits. The strange things started with this:
$ git rebase MY-NEW-BASE
First, rewinding head to replay your work on top of it...
Applying: SOME COMMIT
Applying: SOME OTHER COMMIT
...
Applying: COMMIT A
Applying: COMMIT B
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
error: Your local changes to the following files would be overwritten by merge:
some/source.file
Please, commit your changes or stash them before you can merge.
Aborting
Failed to merge in the changes.
Patch failed at 0014 COMMIT B
The copy of the patch that failed is found in:
/path/to/my/repo/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Now, what is strange about this is that the failed patch actually applies cleanly:
$ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch
patching file some/source.file
$
And there is no subtle merge issue here, either: That patch is the only one to have touched the surrounding code since 1999! There is no source of conflict there!
Anyway. The tale gets stranger, as I was trying to do this again (no changes were made to the repos in between, this is a straight continuation from above):
$ git rebase --abort
$ git rebase MY-NEW-BASE
First, rewinding head to replay your work on top of it...
Applying: SOME COMMIT
Applying: SOME OTHER COMMIT
...
Applying: COMMIT A
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
error: Your local changes to the following files would be overwritten by merge:
some/othersource.file
some/yetanother.file
Please, commit your changes or stash them before you can merge.
Aborting
Failed to merge in the changes.
Patch failed at 0013 COMMIT A
The copy of the patch that failed is found in:
/path/to/my/repo/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
So suddenly it fails to apply the commit A, the one before the previously failing commit. Huh? But again, the failing patch applies cleanly (and after all, rebase was able to apply it in my previous attempt). And again, the patch actually applies cleanly. So one more try:
$ git rebase --abort
$ git rebase MY-NEW-BASE
First, rewinding head to replay your work on top of it...
Applying: SOME COMMIT
Applying: SOME OTHER COMMIT
...
Applying: COMMIT A
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
error: Your local changes to the following files would be overwritten by merge:
some/othersource.file
Please, commit your changes or stash them before you can merge.
Aborting
Failed to merge in the changes.
Patch failed at 0013 COMMIT A
The copy of the patch that failed is found in:
/path/to/my/repo/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Again it fails in commit A -- but this time, it only thinks one file is problematic. HUH? Again, the patch actually applies cleanly:
$ patch -p1 < /path/to/my/repo/.git/rebase-apply/patch
patching file some/othersource.file
patching file some/yetanother.file
At this point, things stabilized, and when I now abort and reattempt the merge, it always fails in the same way. This time trying to apply a change to a code comment that was last changed in 1997 (though for one hunk, a few lines before the changed lines, there is a line that was changed in 2008... but I assure you, that line is there in the ancestors of both the branch I want to rebase, and also in the MY-NEW-BASE branch I rebase onto).
Something seems to be really fishy here and I wonder if anybody has an idea what's going wrong here. Is this a bug in git? Is my repos broken in some way? Note that "git fsck" reported nothing except some dangling objects. Any other ideas?
Cheers,
Max
^ permalink raw reply
* Questions/investigations on git-subtree and tags
From: Jeremy Rosen @ 2013-03-07 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <1492019317.191838.1362650820122.JavaMail.root@openwide.fr>
Hello everybody
I am trying to use git-subtree to follow a subproject but I have a couple of problems and I am not sure if I am doing something wrong
Basically I am trying to use a tag on the subproject as my "base" for the subproject but subtree doesn't seem to handle that properly
my first attempt was to simply do
"git subtree add --squash git://git.buildroot.net/buildroot 2013.02"
but subtree refused, telling me that the SHA of the tag is not a valid commit.
Ok it makes sense, though I think this is a very valid use-case...
so I tried
"git subtree add git://git.buildroot.net/buildroot 2013.02^{commit}"
which was refused because git fetch can't parse the ^{commit} marker.
Again it makes sense, but I really want to start from that tag.
so I tried
"git fetch git://git.buildroot.net/buildroot 2013.02"
"git subtree add --squash FETCH_HEAD"
which worked. Ok at that point I am slightly abusing git subtree, but it seems a valid usage
except that this last attempt causes serious problems when trying to split out the tree again
the call to "git commit-tree" within "git subtree split" complains that the SHA of the parent
is not a valid commit SHA. Which is true, it's the SHA of the tag.
At this point I am not sure if I am abusing subtree, if I have a legitimate but unimplemented use-case and how to
fix/implement it.
the squash-commit message only contains the SHA of the tag, should it contain the SHA of the commit ?
"subtree split" can only handle commit SHA, should it somehow follow tag SHA too ? how ?
this is probably a trivial fix for someone with good knowledge of git-subtree but i'm not there yet, so any hint would be welcomed
Regards
Jérémy Rosen
fight key loggers : write some perl using vim
^ permalink raw reply
* Re: [PATCH] In partial SVN merges, the ranges contains additional character "*"
From: Eric Wong @ 2013-03-07 10:44 UTC (permalink / raw)
To: Jan Pešta; +Cc: git, Junio C Hamano, Matthieu Moy, Sam Vilain
In-Reply-To: <000001ce1ab2$903fbc40$b0bf34c0$@certicon.cz>
(adding Sam to the Cc:, I rely on him for SVN merge knowledge)
Jan Pešta <jan.pesta@certicon.cz> wrote:
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a non-inheritable mergeinfo range.
> The '*' means that only the path on which the mergeinfo is explicitly set
> has had this range merged into it.
Jan: can you write a better commit message to explain what your
patch fixes/changes, and why we do it?
Something like:
Subject: [PATCH] git svn: ignore partial svn:mergeinfo
<explain why we ignore partial svn:mergeinfo in the body>
See Documentation/SubmittingPatches for hints. Thanks!
> Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
> ---
> perl/Git/SVN.pm | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
> index 0ebc68a..74d49bb 100644
> --- a/perl/Git/SVN.pm
> +++ b/perl/Git/SVN.pm
> @@ -1493,6 +1493,11 @@ sub lookup_svn_merge {
> my @merged_commit_ranges;
> # find the tip
> for my $range ( @ranges ) {
> + if ($range =~ /[*]$/) {
> + warn "W:Ignoring partial merge in svn:mergeinfo "
> + ."dirprop: $source:$range\n";
> + next;
> + }
> my ($bottom, $top) = split "-", $range;
> $top ||= $bottom;
> my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
> --
^ permalink raw reply
* Re: [PATCH] format-patch: RFC 2047 says multi-octet character may not be split
From: Kirill Smelkov @ 2013-03-07 10:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Komissarov, git, Jan H. Schönherr
In-Reply-To: <7vd2vcqv1y.fsf@alter.siamese.dyndns.org>
Junio,
On Wed, Mar 06, 2013 at 09:47:53AM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@mns.spb.ru> writes:
>
> > Intro
> > -----
>
> Drop this. We know the beginning part is "intro" already ;-)
:)
> > Subject: .... föö bar
> >
> > encoding
> >
> > Subject: =?UTF-8?q?....=20f=C3=B6=C3=B6?=
> > =?UTF-8?q?=20bar?=
> >
> > is correct, and
> >
> > Subject: =?UTF-8?q?....=20f=C3=B6=C3?= <-- NOTE ö is broken here
> > =?UTF-8?q?=B6=20bar?=
> >
> > is not, because "ö" character UTF-8 encoding C3 B6 is split here across
> > adjacent encoded words.
>
> The above is an important part to keep in the log message.
> Everything above that I snipped can be left out for brevity.
>
> > As it is now, format-patch does not respect "multi-octet charactes may
> > not be split" rule, and so sending patches with non-english subject has
> > issues:
> >
> > The problematic case shows in mail readers as ".... fö?? bar".
>
> But the log message lacks crucial bits of information before you
> start talking about your solution. Where does it go wrong? What
> did the earlier attempt bafc478..41dd00bad miss? This can be fixed
> trivially by replacing the above (and the "solution" section),
> perhaps like this:
>
> Even though an earlier attempt (bafc478..41dd00bad) cleaned
> up RFC 2047 encoding, pretty.c::add_rfc2047() still decides
> where to split the output line by going through the input
> one byte at a time, and potentially splits a character in
> the middle. A subject line may end up showing like this:
>
> The problematic case shows in mail readers as ".... fö?? bar".
>
> Instead, make the loop grab one _character_ at a time and
> determine its output length to see where to break the output
> line. Note that this version only knows about UTF-8, but the
> logic to grab one character is abstracted out in mbs_chrlen()
> function to make it possible to extend it to other encodings.
I agree my description was messy and thanks for reworking and clarifying
it - your version is much better.
I'll use its slight variation for the updated patch.
> > + while (len) {
> > + /*
> > + * RFC 2047, section 5 (3):
> > + *
> > + * Each 'encoded-word' MUST represent an integral number of
> > + * characters. A multi-octet character may not be split across
> > + * adjacent 'encoded- word's.
> > + */
> > + const unsigned char *p = (const unsigned char *)line;
> > + int chrlen = mbs_chrlen(&line, &len, encoding);
> > + int is_special = (chrlen > 1) || is_rfc2047_special(*p, type);
> >
> > /*
> > * According to RFC 2047, we could encode the special character
> > @@ -367,16 +376,18 @@ static void add_rfc2047(struct strbuf *sb, const char *line, int len,
> > * causes ' ' to be encoded as '=20', avoiding this problem.
> > */
> >
> > + if (line_len + 2 + (is_special ? 3*chrlen : 1) > max_encoded_length) {
>
> Always have SP around binary operators such as '*' (multiplication).
ok, but note that's just a matter of style, and if one is used to code
formulas, _not_ having SP is more convenient sometimes.
> I would actually suggest adding an extra variable "encoded_len" and
> do something like this:
>
> /* "=%02X" times num_char, or the byte itself */
> encoded_len = is_special ? 3 * num_char : 1;
> if (max_encoded_length < line_len + 2 + encoded_len) {
> /* It will not fit---break the line */
> ...
Right. Actually if we add encoded_len, adding encoded_fmt is tempting
const char *encoded_fmt = is_special ? "=%02X" : "%c";
and then encoding part simplifies to just unconditional
for (i = 0; i < chrlen; i++)
strbuf_addf(sb, encoded_fmt, p[i]);
line_len += encoded_len;
> You may also want to say what the hardcoded "2" is about in the
> comment there.
ok.
> > diff --git a/utf8.c b/utf8.c
> > index 8f6e84b..7911b58 100644
> > --- a/utf8.c
> > +++ b/utf8.c
> > @@ -531,3 +531,42 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> > return out;
> > }
> > #endif
> > +
> > +/*
> > + * Returns first character length in bytes for multi-byte `text` according to
> > + * `encoding`.
> > + *
> > + * - The `text` pointer is updated to point at the next character.
> > + * - When `remainder_p` is not NULL, on entry `*remainder_p` is how much bytes
> > + * we can consume from text, and on exit `*remainder_p` is reduced by returned
> > + * character length. Otherwise `text` is treated as limited by NUL.
> > + */
> > +int mbs_chrlen(const char **text, size_t *remainder_p, const char *encoding)
> > +{
> > + int chrlen;
> > + const char *p = *text;
> > + size_t r = (remainder_p ? *remainder_p : INT_MAX);
>
> Ugly, and more importantly I suspect this is wrong because size_t is
> not signed and INT_MAX is.
Why is it ugly? There is similiar snippet in pick_one_utf8_char():
/*
* A caller that assumes NUL terminated text can choose
* not to bother with the remainder length. We will
* stop at the first NUL.
*/
remainder = (remainder_p ? *remainder_p : 999);
only ad-hoc 999 is used there.
I agree about INT_MAX being signed - my mistake - better change it to
SIZE_MAX or ((size_t)-1) for portability, but otherwise the construct is
imho ok. I'll change to SIZE_MAX since it is alredy used in Git.
Computing r in the beginning simplifies following code.
> > + if (r < 1)
> > + return 0;
> > +
> > + if (is_encoding_utf8(encoding)) {
> > + pick_one_utf8_char(&p, &r);
> > +
> > + chrlen = p ? (p - *text)
> > + : 1 /* not valid UTF-8 -> raw byte sequence */;
> > + }
> > + else {
> > + /* TODO use iconv to decode one char and obtain its chrlen
> > + *
> > + * for now, let's treat encodings != UTF-8 as one-byte
> > + */
> > + chrlen = 1;
>
> /*
> * We format our multi-line
> * comments like this
> */
ok, I agree.
> Thanks.
Thanks too,
Kirill
Interdiff and updated patch follows:
diff -u b/pretty.c b/pretty.c
--- b/pretty.c
+++ b/pretty.c
@@ -369,4 +369,8 @@
int is_special = (chrlen > 1) || is_rfc2047_special(*p, type);
+ /* "=%02X" * chrlen, or the byte itself */
+ const char *encoded_fmt = is_special ? "=%02X" : "%c";
+ int encoded_len = is_special ? 3 * chrlen : 1;
+
/*
* According to RFC 2047, we could encode the special character
@@ -376,20 +380,15 @@
* causes ' ' to be encoded as '=20', avoiding this problem.
*/
- if (line_len + 2 + (is_special ? 3*chrlen : 1) > max_encoded_length) {
+ if (line_len + encoded_len + /* ?= */2 > max_encoded_length) {
+ /* It will not fit---break the line */
strbuf_addf(sb, "?=\n =?%s?q?", encoding);
line_len = strlen(encoding) + 5 + 1; /* =??q? plus SP */
}
- if (is_special) {
- for (i = 0; i < chrlen; i++) {
- strbuf_addf(sb, "=%02X", p[i]);
- line_len += 3;
- }
- } else {
- strbuf_addch(sb, *p);
- line_len++;
- }
+ for (i = 0; i < chrlen; i++)
+ strbuf_addf(sb, encoded_fmt, p[i]);
+ line_len += encoded_len;
}
strbuf_addstr(sb, "?=");
}
diff -u b/utf8.c b/utf8.c
--- b/utf8.c
+++ b/utf8.c
@@ -545,7 +545,7 @@
{
int chrlen;
const char *p = *text;
- size_t r = (remainder_p ? *remainder_p : INT_MAX);
+ size_t r = (remainder_p ? *remainder_p : SIZE_MAX);
if (r < 1)
return 0;
@@ -557,8 +557,8 @@
: 1 /* not valid UTF-8 -> raw byte sequence */;
}
else {
- /* TODO use iconv to decode one char and obtain its chrlen
- *
+ /*
+ * TODO use iconv to decode one char and obtain its chrlen
* for now, let's treat encodings != UTF-8 as one-byte
*/
chrlen = 1;
---- 8< ----
From 46b9cddc63c07cb5513cfbf6d20aaaa98c66bcdf Mon Sep 17 00:00:00 2001
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Wed, 6 Mar 2013 14:28:46 +0400
Subject: [PATCH v2] format-patch: RFC 2047 says multi-octet character may not be split
Even though an earlier attempt (bafc478..41dd00bad) cleaned
up RFC 2047 encoding, pretty.c::add_rfc2047() still decides
where to split the output line by going through the input
one byte at a time, and potentially splits a character in
the middle. A subject line may end up showing like this:
".... fö?? bar". (instead of ".... föö bar".)
if split incorrectly.
RFC 2047, section 5 (3) explicitly forbids such beaviour
Each 'encoded-word' MUST represent an integral number of
characters. A multi-octet character may not be split across
adjacent 'encoded- word's.
that means that e.g. for
Subject: .... föö bar
encoding
Subject: =?UTF-8?q?....=20f=C3=B6=C3=B6?=
=?UTF-8?q?=20bar?=
is correct, and
Subject: =?UTF-8?q?....=20f=C3=B6=C3?= <-- NOTE ö is broken here
=?UTF-8?q?=B6=20bar?=
is not, because "ö" character UTF-8 encoding C3 B6 is split here across
adjacent encoded words.
To fix the problem, make the loop grab one _character_ at a time and
determine its output length to see where to break the output line. Note
that this version only knows about UTF-8, but the logic to grab one
character is abstracted out in mbs_chrlen() function to make it possible
to extend it to other encodings with the help of iconv in the future.
(With help from Junio C Hamano <gitster@pobox.com>)
Cc: Jan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
pretty.c | 34 ++++++++++++++++++++++------------
t/t4014-format-patch.sh | 27 ++++++++++++++-------------
utf8.c | 39 +++++++++++++++++++++++++++++++++++++++
utf8.h | 2 ++
4 files changed, 77 insertions(+), 25 deletions(-)
diff --git a/pretty.c b/pretty.c
index b57adef..c5fae69 100644
--- a/pretty.c
+++ b/pretty.c
@@ -345,7 +345,7 @@ static int needs_rfc2047_encoding(const char *line, int len,
return 0;
}
-static void add_rfc2047(struct strbuf *sb, const char *line, int len,
+static void add_rfc2047(struct strbuf *sb, const char *line, size_t len,
const char *encoding, enum rfc2047_type type)
{
static const int max_encoded_length = 76; /* per rfc2047 */
@@ -355,9 +355,22 @@ static void add_rfc2047(struct strbuf *sb, const char *line, int len,
strbuf_grow(sb, len * 3 + strlen(encoding) + 100);
strbuf_addf(sb, "=?%s?q?", encoding);
line_len += strlen(encoding) + 5; /* 5 for =??q? */
- for (i = 0; i < len; i++) {
- unsigned ch = line[i] & 0xFF;
- int is_special = is_rfc2047_special(ch, type);
+
+ while (len) {
+ /*
+ * RFC 2047, section 5 (3):
+ *
+ * Each 'encoded-word' MUST represent an integral number of
+ * characters. A multi-octet character may not be split across
+ * adjacent 'encoded- word's.
+ */
+ const unsigned char *p = (const unsigned char *)line;
+ int chrlen = mbs_chrlen(&line, &len, encoding);
+ int is_special = (chrlen > 1) || is_rfc2047_special(*p, type);
+
+ /* "=%02X" * chrlen, or the byte itself */
+ const char *encoded_fmt = is_special ? "=%02X" : "%c";
+ int encoded_len = is_special ? 3 * chrlen : 1;
/*
* According to RFC 2047, we could encode the special character
@@ -367,18 +380,15 @@ static void add_rfc2047(struct strbuf *sb, const char *line, int len,
* causes ' ' to be encoded as '=20', avoiding this problem.
*/
- if (line_len + 2 + (is_special ? 3 : 1) > max_encoded_length) {
+ if (line_len + encoded_len + /* ?= */2 > max_encoded_length) {
+ /* It will not fit---break the line */
strbuf_addf(sb, "?=\n =?%s?q?", encoding);
line_len = strlen(encoding) + 5 + 1; /* =??q? plus SP */
}
- if (is_special) {
- strbuf_addf(sb, "=%02X", ch);
- line_len += 3;
- } else {
- strbuf_addch(sb, ch);
- line_len++;
- }
+ for (i = 0; i < chrlen; i++)
+ strbuf_addf(sb, encoded_fmt, p[i]);
+ line_len += encoded_len;
}
strbuf_addstr(sb, "?=");
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 78633cb..b993dae 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -837,25 +837,26 @@ Subject: [PATCH] =?UTF-8?q?f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
=?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
=?UTF-8?q?=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20?=
=?UTF-8?q?bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6?=
- =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3?=
- =?UTF-8?q?=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3?=
- =?UTF-8?q?=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
+ =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
+ =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
=?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
=?UTF-8?q?=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20?=
=?UTF-8?q?bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6?=
- =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3?=
- =?UTF-8?q?=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3?=
- =?UTF-8?q?=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
+ =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
+ =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
=?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
=?UTF-8?q?=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20?=
=?UTF-8?q?bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6?=
- =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3?=
- =?UTF-8?q?=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
- =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3?=
- =?UTF-8?q?=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
- =?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
+ =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
+ =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
+ =?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
+ =?UTF-8?q?=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20?=
+ =?UTF-8?q?bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6?=
+ =?UTF-8?q?=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6?=
+ =?UTF-8?q?=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
+ =?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
+ =?UTF-8?q?=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20?=
+ =?UTF-8?q?bar?=
EOF
test_expect_success 'format-patch wraps extremely long subject (rfc2047)' '
rm -rf patches/ &&
diff --git a/utf8.c b/utf8.c
index 8f6e84b..7f64857 100644
--- a/utf8.c
+++ b/utf8.c
@@ -531,3 +531,42 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
return out;
}
#endif
+
+/*
+ * Returns first character length in bytes for multi-byte `text` according to
+ * `encoding`.
+ *
+ * - The `text` pointer is updated to point at the next character.
+ * - When `remainder_p` is not NULL, on entry `*remainder_p` is how much bytes
+ * we can consume from text, and on exit `*remainder_p` is reduced by returned
+ * character length. Otherwise `text` is treated as limited by NUL.
+ */
+int mbs_chrlen(const char **text, size_t *remainder_p, const char *encoding)
+{
+ int chrlen;
+ const char *p = *text;
+ size_t r = (remainder_p ? *remainder_p : SIZE_MAX);
+
+ if (r < 1)
+ return 0;
+
+ if (is_encoding_utf8(encoding)) {
+ pick_one_utf8_char(&p, &r);
+
+ chrlen = p ? (p - *text)
+ : 1 /* not valid UTF-8 -> raw byte sequence */;
+ }
+ else {
+ /*
+ * TODO use iconv to decode one char and obtain its chrlen
+ * for now, let's treat encodings != UTF-8 as one-byte
+ */
+ chrlen = 1;
+ }
+
+ *text += chrlen;
+ if (remainder_p)
+ *remainder_p -= chrlen;
+
+ return chrlen;
+}
diff --git a/utf8.h b/utf8.h
index 501b2bd..1f8ecad 100644
--- a/utf8.h
+++ b/utf8.h
@@ -22,4 +22,6 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
#define reencode_string(a,b,c) NULL
#endif
+int mbs_chrlen(const char **text, size_t *remainder_p, const char *encoding);
+
#endif
--
1.8.2.rc2.353.gd2380b4
^ permalink raw reply related
* Re: Questions/investigations on git-subtree and tags
From: Paul Campbell @ 2013-03-07 11:00 UTC (permalink / raw)
To: Jeremy Rosen; +Cc: git
In-Reply-To: <822188477.192374.1362651959144.JavaMail.root@openwide.fr>
On Thu, Mar 7, 2013 at 10:25 AM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
> Hello everybody
>
>
> I am trying to use git-subtree to follow a subproject but I have a couple of problems and I am not sure if I am doing something wrong
>
> Basically I am trying to use a tag on the subproject as my "base" for the subproject but subtree doesn't seem to handle that properly
>
>
> my first attempt was to simply do
>
> "git subtree add --squash git://git.buildroot.net/buildroot 2013.02"
>
> but subtree refused, telling me that the SHA of the tag is not a valid commit.
> Ok it makes sense, though I think this is a very valid use-case...
>
> so I tried
>
> "git subtree add git://git.buildroot.net/buildroot 2013.02^{commit}"
>
> which was refused because git fetch can't parse the ^{commit} marker.
> Again it makes sense, but I really want to start from that tag.
>
>
> so I tried
>
> "git fetch git://git.buildroot.net/buildroot 2013.02"
> "git subtree add --squash FETCH_HEAD"
>
> which worked. Ok at that point I am slightly abusing git subtree, but it seems a valid usage
>
> except that this last attempt causes serious problems when trying to split out the tree again
>
> the call to "git commit-tree" within "git subtree split" complains that the SHA of the parent
> is not a valid commit SHA. Which is true, it's the SHA of the tag.
>
>
> At this point I am not sure if I am abusing subtree, if I have a legitimate but unimplemented use-case and how to
> fix/implement it.
>
> the squash-commit message only contains the SHA of the tag, should it contain the SHA of the commit ?
>
> "subtree split" can only handle commit SHA, should it somehow follow tag SHA too ? how ?
>
> this is probably a trivial fix for someone with good knowledge of git-subtree but i'm not there yet, so any hint would be welcomed
>
> Regards
>
> Jérémy Rosen
>
Hi Jérémy,
Git subtree ignores tags from the remote repo.
To follow a project in a subdirectory I would use git-subtree add
selecting a branch, not a tag, from the other repo. Then use
git-subtree pull to keep yourself updated.
e.g.
To add:
git subtree add --prefix=$subdir $repo $branch
Then to update:
git subtree pull --prefix=$subdir $repo $branch
If you make any changes on the branch and wanted to push them back you
could do that with:
git subtree pull --prefix=$subdir $repo2 $branch2
$repo2 and $branch2 would be different from $repo and $branch if you
wanted to push to your own fork before submitting a pull request.
--
Paul [W] Campbell
^ permalink raw reply
* Re: Questions/investigations on git-subtree and tags
From: Jeremy Rosen @ 2013-03-07 11:05 UTC (permalink / raw)
To: Paul Campbell; +Cc: git
In-Reply-To: <CALeLG_=YQDrgMfOoR_GyNRexWxDqQGhFubmaYwM6pqXJuLnO6A@mail.gmail.com>
>
> Hi Jérémy,
>
> Git subtree ignores tags from the remote repo.
>
is that a design decision or a case of "not implemented yet"
> To follow a project in a subdirectory I would use git-subtree add
> selecting a branch, not a tag, from the other repo. Then use
> git-subtree pull to keep yourself updated.
>
well... yes, but releases are marked by tags, not branches so what I really want is a tag.
I still use git so I have the possibility to update and can traceback what happened later
> e.g.
>
> To add:
>
> git subtree add --prefix=$subdir $repo $branch
>
> Then to update:
>
> git subtree pull --prefix=$subdir $repo $branch
>
ok, that probably works with branches (didn't test)
> If you make any changes on the branch and wanted to push them back
> you
> could do that with:
>
> git subtree pull --prefix=$subdir $repo2 $branch2
>
> $repo2 and $branch2 would be different from $repo and $branch if you
> wanted to push to your own fork before submitting a pull request.
>
shouldn't there be a subtree split somewhere ? IIUC pull is only merge from the remote to my local repo,
not the other way round
> --
> Paul [W] Campbell
>
^ 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