[PATCH 2/2] Fix wrong merge-base invocation preventing detection of up-to-date branches.
---
git-reintegrate | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-reintegrate b/git-reintegrate
index da45239..a6e3cff 100755
--- a/git-reintegrate
+++ b/git-reintegrate
@@ -581,7 +581,7 @@ def status_merge(branch_to_merge = nil)
elsif system(*%w[git merge-base --is-ancestor], branch_to_merge,
$status_base)
state = "+"
verbose_state = "merged to #{$status_base}"
- elsif system(*%w[git-merge-base --is-ancestor], branch_to_merge,
$branch.name)
+ elsif system(*%w[git merge-base --is-ancestor], branch_to_merge,
$branch.name)
state = "*"
verbose_state = "up-to-date"
else
--
2.11.0
[PATCH 1/2] Fix support for merge options.
---
git-reintegrate | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-reintegrate b/git-reintegrate
index a1c17d2..da45239 100755
--- a/git-reintegrate
+++ b/git-reintegrate
@@ -338,7 +338,7 @@ class Integration
def finalize_command(cmd, args, message)
begin
fun = @@map[cmd] || "cmd_#{cmd}".to_sym
- send(fun, message, *args)
+ send(fun, message, *args.split(' '))
rescue NoMethodError
raise Integration::Stop, "Unknown command: #{cmd}"
end
@@ -559,7 +559,7 @@ def do_apply
inst = inst.lines.reject do |line|
next true if line =~ /^base /
if line =~ /^merge (.*)$/
- system(*%W[git merge-base --is-ancestor #{$1} HEAD])
+ system(*%W[git merge-base --is-ancestor #{$1.split(' ')[0]} HEAD])
next true if $?.success?
end
false
@@ -621,7 +621,7 @@ def do_status
when 'base'
$status_base = args
when 'merge'
- status_merge(*args)
+ status_merge(*args.split(' ')[0])
when '.'
status_dot(*args)
else
--
2.11.0
[BUG] git-gui regression in 2.0rcX within submodule
In 2.0rc2, git-gui is unable to work inside submodules, where 1.9.2 did not show such a problem: yann@home:~$ cd /tmp/ yann@home:tmp$ mkdir foo yann@home:tmp$ cd foo/ yann@home:foo$ git init Initialized empty Git repository in /tmp/foo/.git/ yann@home:foo (master)$ git submodule add git://git.debian.org/git/collab-maint/tulip.git debian Cloning into 'debian'... remote: Counting objects: 317, done. remote: Compressing objects: 100% (199/199), done. remote: Total 317 (delta 184), reused 166 (delta 95) Receiving objects: 100% (317/317), 73.81 KiB | 0 bytes/s, done. Resolving deltas: 100% (184/184), done. Checking connectivity... done. yann@home:foo (master)$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached ..." to unstage) new file: .gitmodules new file: debian yann@home:foo (master)$ (cd debian/ && git gui) [errors out after showing the following error dialog] | No working directory ../../../debian: | | couldn't change working directory | to "../../../debian": no such file or | directory strace shows the failing chdir call is from git-gui itself, after getcwd() told him that it is in the dir that is indeed the workdir already. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] rebase not recovering gracefully from repack error
(patches|REBASE 8/9)$ git rebase --continue Applying: Check for __unix__ instead of __linux Applying: Completely disable crash handler on archs other than i386 and amd64 Auto packing the repository for optimum performance. You may also run "git gc" manually. See "git help gc" for more information. error: Could not read a7d470051f53f4e4c9247df752583868a79ec70b fatal: Failed to traverse parents of commit e6d2f264969207e337953717c260d37daa0a8554 error: failed to run repack (patches|REBASE 10/9)$ cat .git/rebase-apply/next 10 (patches|REBASE 10/9)$ The last patch has been dealt with and I consider the rebase done. Rebase would be bombing out without cleaning behind it when the auto repack fails ? On another aspect, I find the repack error is suspect: "git fsck --no-dangling" has nothing to complain about, and the missing commit is the real ancestor of a grafted commit. I suppose it has been gc'd by a buggy git version, as I recall seeing such a fix on the list some time ago. (yes, I shouldn't be using grafts any more, but that particular one dates back to 2006 ;) -- Yann [v1.8.4] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUGLET] Short form of options with an optional parameter are not very clear
I just stumbled over the "git status -uno" form, and it took me some time to realize that "no" was a parameter to -u, rather than aggregated (and undocumented) -n and -o. Whereas the manpage does document the "-u[]" syntax, which dissipate the misunderstanding, --help output does not, listing "-u" in a way that appears not to take any option. Looks like the --help output would gain from having the optional parameter displayed in the short form... -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUGLET] git bisect visualize does not show BISECT_HEAD
[v1.8.3.4]
"git bisect visualize" when run without --no-checkout has the standard gitk
handling of
"HEAD" showing what the current revision being tested is (as a yellow node).
Now when using --no-checkout, the information "current revision" we may be
looking for
has nothing to do with HEAD any longer: we need BISECT_HEAD instead - and if by
any chance
HEAD would happen to be in the displayed scope, the user may do wrong
assumptions about
it (maybe).
Wondering whether there would be any flags that would pass to gitk through
"bisect visualize",
I naively tried:
$ git bisect visualize -h
usage: git log [] [] [[--] ...]
or: git show [options] ...
--quiet suppress diff output
--source show source
--use-mailmap Use mail map file
--decorate[=...] decorate options
-L Process line range n,m in file, counting from 1
Wandering away from what I was look for:
$ git bisect visualize --decorate
... some git log output
That seems unfortunate in its own right as well...
Back to the problem of visualizing the info, it looks like gitk would need a
way to display
refs that are not displayed by default, when we need them. Something like:
gitk --explicit-refs=BISECT_HEAD,refs/whatever
That would also be helpful when one tries to look at the reflog graphically:
whereas
gitk accepts to show whatever@{1} and friends, it never tells us which revision
corresponds
to which reflog entry, and --explicit-refs=whatever@{1},whatever@{2} would help
here, as would
something like --explicit-refs=whatever@{*} or --explicit-refs=whatever@{1..5},
but that starts
to be more tricky to formalize.
Thoughts, anyone ?
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] rebase should desambiguate abbreviated hashes before starting
I just ran into a funny edge-case when doing a long rebase: one of the rewritten commits got a sha1 starting with one of the abbreviated sha1's of a commit still to be applied. As a result, the rebase stopped with a funny-looking "short SHA1 ... was ambiguous", which would not have occured if the shortened sha1's presented to the user were expanded to full sha1's before starting the rebase. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Itches with the current rev spec
On Mon, 29 Apr 2013 20:38:03 +0530 Ramkumar Ramachandra wrote: > 3. "Range" is not an inherent property of A..B or A...B. There are no > "revision ranges". Well, that could be seen as a problem, the .. syntax being commonly associated with the concept of range. > 4. Every command is free to interpret positive and negative commits as > it sees fit. Since there is no ordering, it must never treat one > negative commit differently from another negative commit, or one > positive commit differently from another positive commit. > > show takes a list of positive commits and shows all of them. > > log will show all the commits reachable from positive commits, and > exclude all the commits reachable from negative commits. Here, the > "list of commits" are interpreted differently from the show case. > > diff can either take two positive commits or one positive + one > negative commit. In the latter case, it swaps the arguments and > treats both as positive commits. > > rebase can take one negative commit and one positive commit. The > commits reachable from the positive commit, but not from the negative > commit are replayed onto the negative commit. Now, we can use --onto= > to override the commit onto which to replay. But the fundamental > constraint remains: rebase _cannot_ make this --onto= parameter part > of the normal rev spec (we only have two types of commits: positive > and negative to which we can assign different meanings). > -- Don't forget the particular situation of cherry-pick, which shows a situation where we may want to specify a set of single commits and ranges, but for which the current mechanisms cause a problem. See: http://thread.gmane.org/gmane.comp.version-control.git/14/focus=200058 -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Itches with the current rev spec
>2. git rebase -i master fails unless I've rebased my branch on top of >master. I always wished I could do the equivalent of 'git rebase -i >master..', but I can't. Can we give the A..B syntax a new meaning in >the context of rebase, namely $(git merge-base A B)? If I understand well, you're refering to a problem that also annoys me, ie. using "rebase -i" to just edit your local commits, without rebasing onto the lastest revision on the upstream branch, right ? That is, just another wart of having a single command for arguably-different use cases, or of having the single-argument version of rebase use that argument for 2 very different things (cut-off point and destination), but I won't try to address either of these today :) In that case, what about just adding a new flag to "rebase -i", that would prevent the single-argument to be interpreted as destination ? I really consider this a workaround for a suboptimal CLI, but since we don't want to change the rebase CLI before at least 2.0, that could fill the gap for now. As for the flag itself, what about --here ? Obviously it would only be meaninglful together with -i, and be exclusive with --onto. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] git reflog on a tag tries to do something unexpected
git reflog, when applied to a tag, should surely bail out saying there is reflog for the requested reference. However, instead it spits out a single line of abbreviated sha1's of an ancestry walk: $ git reflog --decorate v1.8.2.1 5bda18c (tag: v1.8.2.1) 6466fbb 2137ce0 (tag: v1.8.1.6) 4bbb830 0e9b327 ... -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] git gui alert dialogs interfere with each other
(Seen in 1.7.12.3) When launching git gui in a repo where there are 1. lots of (>5000) stashed changes (to do a tree move), and 2. many non-packed files, git gui throws 2 alert dialogs: one saying that it will only show 5000 changed files and ignore the others, which very quickly hidden by the offer to repack. If I decline repacking, then both dialogs are discarded, and the first one, which is quite critical, may not have been seen at all by the user. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOCBUG] git subtree synopsis needs updating
On Mon, 31 Dec 2012 20:51:41 -0600 gree...@obbligato.org wrote: > Yann Dirson writes: > > > As the examples in git-subtree.txt show, the synopsis in the same file > > should > > surely get a patch along the lines of: > > > > -'git subtree' add -P > > +'git subtree' add -P > > > > Failure to specify the repository (by just specifying a local commit) fails > > with > > the cryptic: > > > > warning: read-tree: emptying the index with no arguments is deprecated; > > use --empty > > fatal: just how do you expect me to merge 0 trees? > > Specifying a local branch works fine, though, as does a raw commit > hash. What do you mean by "local commit?" With no arg documented, my understanding was that I should first "git remote add" and fetch the repo in which the branch to be added as subtree lived. This when running "git subtree add", the commit was indeed existing locally. > > As a sidenote it someone wants to do some maintainance, using "." as > > repository when > > the branch to subtree-add is already locally available does not work well > > either > > (fails with "could not find ref myremote/myhead"). > > Seems to work for me. Can you give me the command you're using when you > see the problem? Hm, can't remember exactly how I reached that. But when experimenting to reproduce: $ contrib/subtree/git-subtree.sh add -P foo . origin/maint git fetch . origin/maint >From . * remote-tracking branch origin/maint -> FETCH_HEAD Added dir 'foo' => OK $ contrib/subtree/git-subtree.sh add -P fooo . origin/maint^0 git fetch . origin/maint^0 fatal: Invalid refspec 'origin/maint^0' => a commit is advertised, but in fact it seems to require a refspec -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Tue, 18 Dec 2012 08:09:35 -0800 Junio C Hamano wrote: > Yann Dirson writes: > > > On Mon, 17 Dec 2012 13:14:56 -0800 > > Junio C Hamano wrote: > > > >> Andreas Schwab writes: > >> > >> > Christian Couder writes: > >> > > >> >> Yeah, at one point I wanted to have a command that created to craft a > >> >> new commit based on an existing one. > >> > > >> > This isn't hard to do, you only have to resort to plumbing: > >> > > >> > $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed > >> > s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ > >> > | git hash-object -t commit --stdin -w > >> > bb45cc6356eac6c7fa432965090045306dab7026 > >> > >> Good. I do not think an extra special-purpose command is welcome > >> here. > > > > Well, I'm not sure this is intuitive enough to be useful to the average > > user :) > > I do not understand why you even want to go in the harder route in > the first place, only to complicate things? Although the approach you propose is elegant, it still looks like one could not leave the worktree untouched in the case of creating a merge replace, which the "just forge an arbitrary commit" approach handles easily. It seems the latter would also be more powerful, in that you can create new commits with an arbitrary number of parents, even when merge-octopus would simply refuse to help; and it is has no special case for creating merges. > Is this not intuitive enough? I would say it is a nice read that can help an advanced user to earn some XP - but well, replace refs are also meant for somewhat advanced users :) -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Tue, 18 Dec 2012 13:49:44 +0100 Thomas Rast wrote: > Johannes Sixt writes: > > > Am 12/18/2012 12:00, schrieb Yann Dirson: > >> On Mon, 17 Dec 2012 13:14:56 -0800 > >> Junio C Hamano wrote: > >> > >>> Andreas Schwab writes: > >>> > >>>> Christian Couder writes: > >>>> > >>>>> Yeah, at one point I wanted to have a command that created to craft a > >>>>> new commit based on an existing one. > >>>> > >>>> This isn't hard to do, you only have to resort to plumbing: > >>>> > >>>> $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | > >>>> sed > >>>> s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ > >>>> | git hash-object -t commit --stdin -w > >>>> bb45cc6356eac6c7fa432965090045306dab7026 > >>> > >>> Good. I do not think an extra special-purpose command is welcome > >>> here. > >> > >> Well, I'm not sure this is intuitive enough to be useful to the average > >> user :) > > > > When I played with git-replace in the past, I imagined that it could be > > > >git replace --commit ...commit options... > > > > that would do the trick. > > > > We could implement it with a git-replace--commit helper script that > > generates the replacement commit using the ...commit options... (to be > > defined what this should be), and git-replace would just pick its output > > (the SHA1 of the generated commit) as a substitute for the > > argument that would have to be given without the --commit option. > > I wouldn't even want a script -- we'd end up inventing a complicated > command-line editor for what can simply be done by judicious use of an > actual text editor. How about something like the following? Well, while it does the job, it is still hardly as straightforward as the old "vi .git/info/grafts", or as a single easily-remembered commandline. I was again thinking the only commandline stuff that does not exist currently in git-commit is specifying parents. One possiblity would be to add such an option to git-commit, together with a --replace flag that would cause the new commit to attached a replace ref (not completely unlike --append, in that we're doing some non-default action instead of just adding the changes to a new commit). But well, I don't think we would want to add to git-commit the ability of playing with something else than what's in the index/worktree. Abstracting the commit commandline to make it reusable by a git-replace--commit and possibly other tools that may want to rw-manipulate arbitrary commits could make sense ? > > Documentation/git-replace.txt | 21 + > 1 file changed, 21 insertions(+) > > diff --git i/Documentation/git-replace.txt w/Documentation/git-replace.txt > index 51131d0..2502118 100644 > --- i/Documentation/git-replace.txt > +++ w/Documentation/git-replace.txt > @@ -61,6 +61,27 @@ OPTIONS > Typing "git replace" without arguments, also lists all replace > refs. > > + > +EXAMPLE > +--- > + > +Replacements (and before them, grafts) are often used to replace the > +parent list of a commit. Since commits are stored in a human-readable > +format, you can in fact change any property using the following > +recipe: > + > + > +$ git cat-file commit original_commit >tmp > +$ vi tmp > + > +In the editor, adjust the commit as needed. For example, you can edit > +the parent lists by adding/removing lines starting with "parent". > +When done, replace the original commit with the edited one: > + > +$ git replace original_commit $(git hash-object -w tmp) You probably meant "-t commit" - a sign that it's not so trivial to forge ? > + > + > + > BUGS > > Comparing blobs or trees that have been replaced with those that > > -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Mon, 17 Dec 2012 13:14:56 -0800
Junio C Hamano wrote:
> Andreas Schwab writes:
>
> > Christian Couder writes:
> >
> >> Yeah, at one point I wanted to have a command that created to craft a
> >> new commit based on an existing one.
> >
> > This isn't hard to do, you only have to resort to plumbing:
> >
> > $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed
> > s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
> > | git hash-object -t commit --stdin -w
> > bb45cc6356eac6c7fa432965090045306dab7026
>
> Good. I do not think an extra special-purpose command is welcome
> here.
Well, I'm not sure this is intuitive enough to be useful to the average user :)
Adding git-rev-parse calls for convenience, and calling git-replace, would make
it
a more complete recipe, and we could suggest that as an alias in the collection
that's
in the wiki (which is not even linked any more from git-scm.com btw), but imho
that
would be hiding valuable information in a dark corner.
Anyway, in this form it will only replace a parent with another, whereas a full
graft replacement should allow to write a different number of new parents
instead.
That is, instead of this simple sed, something like:
(NEWPARENTS='parent xxx\nparent yyy\nparent zzz\n; git cat-file commit master |
perl -ne 'BEGIN { $state=0 }; if ($state eq 0) { if (/^parent/) { $state=1 }
else { print } } elsif ($state eq 1) { if (/^author/) { print
"'"$NEWPARENTS"'"; print; $state=2 } } else { print }')
Well, a short bash script should be more readable and possibly faster, but
that's the
idea. Such a script could be a candidate for contrib ?
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Mon, 17 Dec 2012 14:43:59 +0100 Christian Couder wrote: > Hi Yann, > > On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson wrote: > > On Mon, 17 Dec 2012 09:43:53 +0100 > > Thomas Rast wrote: > > > >> Junio C Hamano writes: > >> > >> > >> I suppose there's the additional issue that grafts are much easier to > >> use than replacements if you really only want to replace some parent > >> lists. With replace you need to handcraft the replacement commits, and > >> git-replace(1) unhelpfully does not say this, much less gives an example > >> how to do it. > >> > > > > Right, replace refs can surely be made easier to use. The requirement to > > craft a > > new commit manually is a major step back in ease of use. > > Yeah, at one point I wanted to have a command that created to craft a > new commit based on an existing one. > Perhaps it could be useful when using filter-branch or perhaps it > could reuse some filter-branch code. > > > Maybe something like "git replace -p ..." to just > > provide a simple > > API to the exact graft functionnality would be good. But it would be > > commit-specific, whereas > > replace refs are indeed more generic, and, one could want to rewrite any > > other part of the commit, > > so we could prefer a more general mechanism. > > Yeah I wondered at one point if something like the following would do: > > git replace --parent --parent --author > --commiter ... Yes, modification flags, that would only be allowed when the objects are commits, and would cause creation of a replace commit that's plus modifications. We could then reuse the relevant options from git-commit, and add the missing --parent. But wouldn't it stretch git-replace too much, to add commit-specific behaviour there ? > > Something that could be useful in this respect, would be an --amend like > > option to git-commit, like > > "git commit --replace". But unfortunately it does not allow to change > > parents, and it has the > > drawback of requiring that HEAD points to the commit to be replaced. > > > > So maybe, if there are no other idea, a simple "git graft" command that > > would wrap "git replace", > > would fill the gap. > > It would not be straightforward to call it "graft" if it uses git replace. Well, "git replace" would just be the "implementation detail". The idea would be to keep the concept of a "graft", and just change its implementation. If we care (and we surely do not, it's just a thought experiment ;), we could even provide, for pre-replace gits, a "git graft" implementation that would manipulate info/grafts, together with a docpatch saying that direct manipulation of info/grafts is deprecated. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Mon, 17 Dec 2012 09:43:53 +0100 Thomas Rast wrote: > Junio C Hamano writes: > > > Yann Dirson writes: > > > >> In this respect, they seem to be > >> lacking a few features, when compared to "replace" refs, but they have > >> different > >> uses, ... > > > > Not reallyl; grafts were old hack whose use is still supported with > > its original limitations; replace is meant to replace all uses of > > grafts while removing grafts' largest warts. > > I suppose there's the additional issue that grafts are much easier to > use than replacements if you really only want to replace some parent > lists. With replace you need to handcraft the replacement commits, and > git-replace(1) unhelpfully does not say this, much less gives an example > how to do it. > Right, replace refs can surely be made easier to use. The requirement to craft a new commit manually is a major step back in ease of use. Maybe something like "git replace -p ..." to just provide a simple API to the exact graft functionnality would be good. But it would be commit-specific, whereas replace refs are indeed more generic, and, one could want to rewrite any other part of the commit, so we could prefer a more general mechanism. Something that could be useful in this respect, would be an --amend like option to git-commit, like "git commit --replace". But unfortunately it does not allow to change parents, and it has the drawback of requiring that HEAD points to the commit to be replaced. So maybe, if there are no other idea, a simple "git graft" command that would wrap "git replace", would fill the gap. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Mon, 17 Dec 2012 00:56:06 -0800
Junio C Hamano wrote:
> Yann Dirson writes:
>
> > And we may still want the bug fixed, or would we just list it as a known
> > bug ?
> > At least it does not seem to occur with "replace" refs:
>
> The "replace" was designed to "fix" known limitation of grafts,
> which is _inherent_ to it; the graft information was designed _not_
> to be shared across repositories. The fix was done by by using a
> different mechanism to allow propagating the information across
> repositories.
I see. But from what I observed (without looking at the source), it looks like
when determining which commits are to be pushed, the grafts file is not
"neutralized"
as it should.
> So there is nothing further to fix, except that there is a documentation
> bug you can fix if you didn't find it documented.
Will do.
> Thanks.
>
> >
> > git-test$ rm .git/info/grafts
> > git-test$ echo "fake merge" | git commit-tree master^{tree} -p master^ -p
> > maint
> > b821b2aa00973a47936d7cd25c9a5978b1c839c6
> > git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
> > git-test$ git push origin maint
> > ...
> >50b03b0..79211fe maint -> maint
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano wrote:
> Yann Dirson writes:
>
> > In this respect, they seem to be
> > lacking a few features, when compared to "replace" refs, but they have
> > different
> > uses, ...
>
> Not reallyl; grafts were old hack whose use is still supported with
> its original limitations; replace is meant to replace all uses of
> grafts while removing grafts' largest warts.
OK, I'll take this into account.
But this situation should probably be make more clear in the docs. Currently,
gitrepository-layout.txt describes refs/replace/ (and shallow) by reference to
grafts,
and those are not marked as discouraged-use or anything.
And we may still want the bug fixed, or would we just list it as a known bug ?
At least it does not seem to occur with "replace" refs:
git-test$ rm .git/info/grafts
git-test$ echo "fake merge" | git commit-tree master^{tree} -p master^ -p maint
b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git push origin maint
...
50b03b0..79211fe maint -> maint
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Wed, 12 Dec 2012 09:44:32 +0100 Yann Dirson wrote: > In fact, I even looked for a way to specify an alternate (or supplementary) > grafts file for this drafting work, so only well-controlled git invocations > would see them, whereas the others would just ignore them, and could not find > any - nor could I identify an existing way of disabling the use of grafts by > other means than moving it out of the way. In this respect, they seem to be > lacking a few features, when compared to "replace" refs, but they have > different > uses, and just using the latter as a drafting area is just not adequate. > > I thought about adding support for a GIT_GRAFTS_FILE envvar, which would > default to $GITDIR/info/grafts, or maybe with a more general addition of a > GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that > useful. My bad on this point: there *is* a GIT_GRAFT_FILE envvar, it is just undocumented. In fact it is not the only one: git.git$ for v in $(git grep define.*_ENVIRONMENT master -- cache.h | cut -d'"' -f2|grep ^GIT_); do git grep -q $v master -- Documentation || echo "missing $v"; done missing GIT_GRAFT_FILE missing GIT_CONFIG_PARAMETERS -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Tue, 11 Dec 2012 10:15:23 -0800 Junio C Hamano wrote: > Yann Dirson writes: > > > There seems to be some bad interactions between git-push and grafts. > > The problem seems to occur when a commit that exists in the remote > > repo is subject to a graft in the local repo, and we try to push one > > of the fake parents. > > History tweaking by grafts is only visible inside your local > repository and objects are not rewritten, and grafts are not > transferred across repositories. They were invented to be used as a > stop-gap measure until you filter-branch the history before > publishing (or if you do not publish, then you can keep using your > local grafts). > > Isn't this well known? Perhaps we would need to document it better. I am well aware of that, and did not intend to push any grafted commit. I am attempting to push a well-formed commit, which happens to be used as a grafted commit's fake parent, and my interpretation is that git reacts as if it was considering that the remote already had that commit, possibly because it would not ignore grafts when deciding which commits are already known to the remote. > What you can do is to use "replace" instead and publish the replace > refs, I think. Object transfer will then follow the true parenthood > connectivity and people who choose to use the same replacement as > you do can fetch the replace ref from you (this will grab objects > necessary to complete the alternative history) and install it. I am only using grafts as a temporary and lightweight drafting area, before setting the results in stone - although in my case it will be with filter-branch rather than replace, but the idea is the same. I just got bitten when attempting to push a valid branch while the grafts were in effect, when in fact they should have had no influence at all. In fact, I even looked for a way to specify an alternate (or supplementary) grafts file for this drafting work, so only well-controlled git invocations would see them, whereas the others would just ignore them, and could not find any - nor could I identify an existing way of disabling the use of grafts by other means than moving it out of the way. In this respect, they seem to be lacking a few features, when compared to "replace" refs, but they have different uses, and just using the latter as a drafting area is just not adequate. I thought about adding support for a GIT_GRAFTS_FILE envvar, which would default to $GITDIR/info/grafts, or maybe with a more general addition of a GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that useful. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Cannot push some grafted branches
There seems to be some bad interactions between git-push and grafts. The problem seems to occur when a commit that exists in the remote repo is subject to a graft in the local repo, and we try to push one of the fake parents. The problem was first seen on 1.7.12.3 in a private repo, and I could reproduce it using 1.8.1.rc0, as shown below. 1.7.10.4 seems even more affected, with something looking like a memory corruption issue. Here is the test: $ git clone git.git git-test Cloning into 'git-test'... done. Checking out files: 100% (2518/2518), done. $ cd git-test/ git-test$ git co maint Branch maint set up to track remote branch maint from origin. Switched to a new branch 'maint' git-test$ echo >> README git-test$ git commit -a -m "test" [maint 0708279] test 1 file changed, 1 insertion(+) git-test$ echo $(git rev-parse origin/master; git rev-parse origin/master^; git rev-parse HEAD) > .git/info/grafts git-test$ git version git version 1.8.1.rc0 git-test$ git push origin maint Total 0 (delta 0), reused 0 (delta 0) fatal: bad object 0708279e168b52003234dd23601796b3b12e278b fatal: bad object 0708279e168b52003234dd23601796b3b12e278b To /home/localadm/softs/git.git ! [remote rejected] maint -> maint (missing necessary objects) error: failed to push some refs to '/home/localadm/softs/git.git' $ git version git version 1.7.10.4 git-test$ git push origin maint Total 0 (delta 0), reused 0 (delta 0) fatal: bad object 0708279e168b52003234dd23601796b3b12e278b fatal: bad object 0708279e168b52003234dd23601796b3b12e278b Auto packing the repository for optimum performance. fatal: protocol error: bad line length character: Remo error: error in sideband demultiplexer error: >S��ŋJ�jB�;�x'��R died of signal 13 To /home/localadm/softs/git.git ! [remote rejected] maint -> maint (missing necessary objects) error: failed to push some refs to '/home/localadm/softs/git.git' -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOCBUG] git subtree synopsis needs updating
On Sat, 20 Oct 2012 21:40:03 +0200 Herman van Rink wrote: > On 10/19/2012 03:21 PM, Yann Dirson wrote: > > As the examples in git-subtree.txt show, the synopsis in the same file > > should > > surely get a patch along the lines of: > > > > -'git subtree' add -P > > +'git subtree' add -P > > > > Failure to specify the repository (by just specifying a local commit) fails > > with > > the cryptic: > > > > warning: read-tree: emptying the index with no arguments is deprecated; > > use --empty > > fatal: just how do you expect me to merge 0 trees? > > > > > > Furthermore, the doc paragraph for add, aside from mentionning > > , also > > mentions a which the synopsis does not show either. > > > > > > As a sidenote it someone wants to do some maintainance, using "." as > > repository when > > the branch to subtree-add is already locally available does not work well > > either > > (fails with "could not find ref myremote/myhead"). > > > > The version of subtree in contrib is rather out-dated unfortunately. > > I've collected a bunch of patches in > https://github.com/helmo/git/tree/subtree-updates Ah, it's nice to see subtree updates. Any plans to get them merged anytime soon ? I guess you may want to rebase the patches from https://github.com/helmo/git-subtree, the subtree-updates patch looks like a "subtree merge --squash" result, and is not really suitable for reviewing on the list. > The documentation issue is also fixed in there. > -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[DOCBUG] git subtree synopsis needs updating
As the examples in git-subtree.txt show, the synopsis in the same file should surely get a patch along the lines of: -'git subtree' add -P +'git subtree' add -P Failure to specify the repository (by just specifying a local commit) fails with the cryptic: warning: read-tree: emptying the index with no arguments is deprecated; use --empty fatal: just how do you expect me to merge 0 trees? Furthermore, the doc paragraph for add, aside from mentionning , also mentions a which the synopsis does not show either. As a sidenote it someone wants to do some maintainance, using "." as repository when the branch to subtree-add is already locally available does not work well either (fails with "could not find ref myremote/myhead"). -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] "git commit" after "cherry-pick -n" conflict clobbers .git/COMMIT_EDITMSG
(only tested with 1.7.10.x for now) ~/softs/linux$ echo foo > .git/COMMIT_EDITMSG ~/softs/linux$ git cherry-pick -n b55f3d92cd error: could not apply b55f3d9... Linux 2.6.32.26 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add ' or 'git rm ' ~/softs/linux$ cat .git/COMMIT_EDITMSG foo So far, so good. But then "git commit" brings me the message from the cherry-picked commit plus the list of conflicted files, and I can verify that it is now the contents of .git/COMMIT_EDITMSG. Surely the fact I passed "-n" should prevent cloberring the message, even in the event of a conflict. I suppose that would imply not creating .git/MERGE_MSG in that case, but just removing it still causes .git/COMMIT_EDITMSG to be clobbered, this time with nothing but the "git status"-derived comments. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Showing all stashed changes in one go
When I have a couple of stashed changes, it gets annoying to
repeatedly call "git stash show -p stash@{N}" until finding the
correct one.
Since "git reflog show stash" already does part of the job, I thought
that adding "-p" there to see the patch would help (at least it would
show the not-yet-staged parts, which would already be a good start).
But the output is then really strange: does it really print the delta
between every two reflog entries ? I can't think of a situation where
it would be was we want - but then, my imagination is known to be
deficient when I hit a situation that does not do what I was expecting
at first :)
Is there another way I missed to get all those stash contents listed,
besides scriptically iterating ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] misplaced space in word diff
Here is a quick test case for a word-diff error, using v1.7.10.4
(debian wheezy package).
Setting up:
tmp$ mkdir foo && cd foo
foo$ git init
Initialized empty Git repository in /tmp/foo/.git/
foo (master)$ echo '*.pydiff=python' > .gitattributes
foo (master)$ echo 'for name in bar.blurb:' > v1.py
foo (master)$ echo 'for name in foo.bar.blurb:' > v2.py
This looks fine:
foo (master)$ git diff --no-index --word-diff=plain v1.py v2.py
diff --git a/v1.py b/v2.py
index a6a079d..2832331 100644
--- a/v1.py
+++ b/v2.py
@@ -1 +1 @@
for name in {+foo.+}bar.blurb:
This however is not:
foo (master)$ git diff --no-index --word-diff=plain v2.py v1.py
diff --git a/v2.py b/v1.py
index 2832331..a6a079d 100644
--- a/v2.py
+++ b/v1.py
@@ -1 +1 @@
for name in[-foo.-] bar.blurb:
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] git rebase not accepting :/ syntax
On Fri, 07 Sep 2012 15:54:49 +0200
Andreas Schwab wrote:
> Yann Dirson writes:
>
> > In 1.7.10.3, "git rebase -i :/Merge" will complain with:
> >
> > fatal: Needed a single revision
> > invalid upstream :/Merge
> >
> > ... whereas "git rev-parse :/Merge" has no problem resolving
> > to a single revision.
>
> git rebase actually calls "git rev-parse :/Merge^0", which due to the
> unlimited nature of :/ doesn't work.
Hm. But then, git rev-parse $(git rev-parse :/Merge}^0 does work, a trivial
patch would appear to make things better.
BTW, git-rebase.sh seems to be quite inconsistent on the use of $() vs. ``,
not to mention the clear preference stated in CodingGuidelines.
I guess I'll find a moment for a couple of patches...
> > OTOH, "git rebase -i HEAD^{/Merge}" does work, and rev-parse resolves
> > it to the same commit.
>
> OTOH, "git rev-parse HEAD^{/Merge}^0" works as expected.
>
> Andreas.
>
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG?] git rebase not accepting :/ syntax
In 1.7.10.3, "git rebase -i :/Merge" will complain with:
fatal: Needed a single revision
invalid upstream :/Merge
... whereas "git rev-parse :/Merge" has no problem resolving
to a single revision. OTOH, "git rebase -i HEAD^{/Merge}" does
work, and rev-parse resolves it to the same commit.
Is that due in some way to the semantic differences between the two
revspecs, or is that just a bug ?
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
