* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-23 17:20 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Hannu Koivisto, Theodore Tso
In-Reply-To: <1232578668-2203-1-git-send-email-charles@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> Previously, git mergetool used cat-file which does not perform git to
> worktree conversion. This changes mergetool to use git checkout-index
> instead which means that the temporary files used for mergetool use the
> correct line endings for the platform.
>
> Signed-off-by: Charles Bailey <charles@hashpling.org>
Sounds like the right thing to do and from a cursory review it looks Ok to
me.
But I do not use mergetool myself, so an Ack from Ted and a Thanks from
whoever reported the breakage would be encouraging ;-).
> +checkout_staged_file () {
> + tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
> +
> + if test $? -eq 0 -a -n "$tmpfile" ; then
> + mv -- "$tmpfile" "$3"
The original redirects into the final destination but this moves. This
will lose the perm bits of the original and obey the perm bits
checkout-index gives you. It will also behave differently when the path
is a symlink. These two differences _may_ well be improvements and/or
bugfixes, but if that is the case please describe them as such.
^ permalink raw reply
* Re: lineups with GIT (or dealing with directory renames)
From: Jakub Narebski @ 2009-01-23 17:25 UTC (permalink / raw)
To: outre; +Cc: git
In-Reply-To: <1232610882661-2196604.post@n2.nabble.com>
outre <spoony.sob@hotmail.com> writes:
[...]
> I tried using "git mv" command and it somewhat solved the problem. After I
> cloned the devel line-up, I used "git rm iWeb.local iWeb.test".
> And now if I edit a file in iWeb.local and do a pull to iWeb.test this file
> gets properly updated while preserving the difference between
> the folder names. But if I add a new file to iWeb.local, and then do a pull
> I get iWeb.local folder added together with the
> new file to the testing line-up.
>
> I was wondering if it is intended behaviour for GIT. And if it is may be
> someone can point me to a better way to setup two line-ups using
> GIT.
I know nothing about line-ups, but the behaviour wrt. wholesame
directory renames is _known_ behavior of git. If one side renames
directory, and other side creates new files in old-name directory,
the old-name directory gets recreated during merging.
I wrote _known_ and not _intendend_ because this can be changed;
there were some patches on git mailing list (I don't know what
happened to them; I think the development stalled) that added
detecting wholesame rename of directories, based on heuristic
content and filename similarity based detection of renames for
individual files.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Junio C Hamano @ 2009-01-23 17:26 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Charles Bailey, git
In-Reply-To: <81bfc67a0901230716i166bfc4chd9a5c0990b0cd3b6@mail.gmail.com>
Caleb Cushing <xenoterracide@gmail.com> writes:
> so does my patch satisfy now? what's it take to get it included in the
> next version of git?
I do not use mergetool myself so I generally do not pay attention to
patches on this tool, but I would want to pick up ones that people
involved in mergetool discussion can agree to be good patches.
There are a few mergetool updates in flight from various authors. How
does your submission compare with others' in both form/presentation and
clarity of logic (remember, I am not keeping track)?
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Junio C Hamano @ 2009-01-23 17:27 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git list, Christian MICHON
In-Reply-To: <20090123185209.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>>> --->8---
>>> Subject: [PATCH] git-am: Add --ignore-date option
>>
>> Good.
>>
>> Leaving "Subject: " in saves me typing, because I do not have to insert it
>> manually when editing the submitted patch in my MUA to chop off everything
>> before the scissors.
>
> I am sorry to ask you a stupid question, but do you mean you want to have
> "Subject: " there, or do you mean you want me to leave that word out?
Sorry for poor use of the language. I want to see "Subject: " on the
line after the scissors. That way, I can remove everything up to the
scissors, and the resulting message body will start with a line that
begins with "Subject: ", which overrides the subject of the e-mail.
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Jakub Narebski @ 2009-01-23 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <20090123171355.GA20413@locahost>
Sébastien Mazy wrote:
> By the way, my renamed remote tracking svn branches now show under
> .git/refs/ as expected.
They were inside file .git/packed-refs
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: lineups with GIT
From: Daniel Barkalow @ 2009-01-23 18:01 UTC (permalink / raw)
To: outre; +Cc: git
In-Reply-To: <1232610882661-2196604.post@n2.nabble.com>
On Wed, 21 Jan 2009, outre wrote:
> I am trying to set up two different line-ups for a project (development and
> testing).
>
> The development line-up is the master, and test line-up pulls data from it.
> The code is the same in both.
> But since the line-ups are served from two different domains one folder in
> the development line-up is called
> iWeb.local, and in the test line-up it is called iWeb.test. That is the only
> difference between the two.
>
> I tried using "git mv" command and it somewhat solved the problem. After I
> cloned the devel line-up, I used "git rm iWeb.local iWeb.test".
> And now if I edit a file in iWeb.local and do a pull to iWeb.test this file
> gets properly updated while preserving the difference between
> the folder names. But if I add a new file to iWeb.local, and then do a pull
> I get iWeb.local folder added together with the
> new file to the testing line-up.
>
> I was wondering if it is intended behaviour for GIT. And if it is may be
> someone can point me to a better way to setup two line-ups using
> GIT.
The best thing is probably to have both of them store everything in a
directory "iWeb", and have whatever process is used to make something
start serving things copy the directory into whatever location it needs.
It helps a lot with git if any two versions that are effectively the same
are exactly the same.
One handy trick is to have a script that reads an untracked file to
determine where and how to arrange stuff for installation. Then you can
have different values in the working directories for the two repositories,
and the same (tracked) script in each repository will do the appropriate
different thing for that repository, while leaving the tracked content for
development exactly the same in testing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] gittutorial: remove misleading note
From: Miklos Vajna @ 2009-01-23 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In the tutorial Alice initializes the repository, and Bob clones it. So
Bob can just do a 'git pull', but Alice will need 'git pull <url>
<branch>'.
The note suggested that the branch parameter is not necessary, which is
no longer true these days.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
The problem was reported by DanC on IRC.
Documentation/gittutorial.txt | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 458fafd..c5d5596 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -308,9 +308,7 @@ alice$ git pull /home/bob/myrepo master
This merges the changes from Bob's "master" branch into Alice's
current branch. If Alice has made her own changes in the meantime,
-then she may need to manually fix any conflicts. (Note that the
-"master" argument in the above command is actually unnecessary, as it
-is the default.)
+then she may need to manually fix any conflicts.
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Charles Bailey @ 2009-01-23 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Hannu Koivisto, Theodore Tso
In-Reply-To: <7v1vuuvt11.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 09:20:10AM -0800, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
>
> > Previously, git mergetool used cat-file which does not perform git to
> > worktree conversion. This changes mergetool to use git checkout-index
> > instead which means that the temporary files used for mergetool use the
> > correct line endings for the platform.
> >
> > Signed-off-by: Charles Bailey <charles@hashpling.org>
>
> Sounds like the right thing to do and from a cursory review it looks Ok to
> me.
>
> But I do not use mergetool myself, so an Ack from Ted and a Thanks from
> whoever reported the breakage would be encouraging ;-).
Yes, please!
I had wondered why I hadn't really noticed about this 'issue' before
as I've used git mergetool on windows with autocrlf set to true quite
a bit. I think that if your mergetool handles LF endings it doesn't
really matter as it's only the temporary files that are affected and
if the mergetool generates LF output files in response to LF input
files then this is resolved to the correct format at the time it is
added to the index in any case.
> > +checkout_staged_file () {
> > + tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
> > +
> > + if test $? -eq 0 -a -n "$tmpfile" ; then
> > + mv -- "$tmpfile" "$3"
>
> The original redirects into the final destination but this moves. This
> will lose the perm bits of the original and obey the perm bits
> checkout-index gives you. It will also behave differently when the path
> is a symlink. These two differences _may_ well be improvements and/or
> bugfixes, but if that is the case please describe them as such.
I hadn't actually thought about the perms thing that much but now that
I do...
This code, and the code that it replaces, only affects the temporary
files that form the basis for the merge. The result/destination file
is as generated by the merge (or rebase).
The redirect version (as is) will not set permissions from the index -
effectively losing information, the new version should (I think - I'm
not an expert in checkout-index) get the 'correct' repository
permissions. I would say that this is, if anything, an improvement.
The ultimate effect really depends on the mergetool and whether the
source file permissions affect the permissions that it sets on the
target file. In the vast majority of cases I would think that it
doesn't have any effect.
Note that symlinks in the repository are not resolved by this code
path so they aren't affected.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [RFC/PATCH v3 2/3] sha1_file: prepare for adding alternates on demand
From: Lars Hjemli @ 2009-01-23 18:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901230041500.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 00:43, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 22 Jan 2009, Lars Hjemli wrote:
>> + if (!quiet)
>> + error("object directory %s does not exist; "
>> + "check .git/objects/info/alternates.",
>> + ent->base);
>
> FWIW my concern is not at all addressed. A future user of add_alt_odb()
> (and possibly your users in rare cases, too) can trigger the error that
> suggests looking into the alternates. Leaving the human user puzzled.
Is it the phrasing of the error message that concerns you (when
invoked from add_alt_odb())?
If so, would something like this be ok/better?
>> + if (!quiet)
>> + error("Alternate object directory %s does not exist ",
>> + ent->base);
--
larsh
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 18:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901230044300.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 00:44, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 22 Jan 2009, Lars Hjemli wrote:
>
>> The new --submodules option is used to trigger inclusion of checked out
>> submodules in the archive.
>>
>> The implementation currently does not verify that the submodule has been
>> registered as 'interesting' in .git/config, neither does it resolve the
>> currently checked out submodule HEAD but instead uses the commit SHA1
>> recorded in the gitlink entry to identify the submodule root tree.
>
> Please understand that I skipped the rest of the patch.
That's too bad, I hoped on some feedback from you on the part of the
commit message which you didn't quote:
>> The plan is to fix these limitations by extending --submodules to allow
>> certain flags/options:
>> a|c|r include any|checked out|registered submodules
>> H resolve submodule HEAD to decide which tree to include
>> g:<name> only include submodules in group <name>
>>
>> The syntax would then become '--submodules[=[a|c|r][H][g:<name>]]' and
>> group membership could be specified in .git/config and/or .gitmodules.
>> The current behavior would then match '--submodules=c' (which might be a
>> sensible default when only --submodules is specified).
Wouldn't such an option address your concern about the
consistency/semantics of the --submodules operation?
--
larsh
^ permalink raw reply
* Re: RFC: git diff colorization idea
From: Jakub Narebski @ 2009-01-23 18:40 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git@vger.kernel.org List
In-Reply-To: <53497057-1ADE-4300-9F35-B218959606FE@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Lately I've been wishing that Git's diff output were colorized in a
> way that combines the standard line-by-line colorizing with the word-
> by-word colorizing you get with --color-words.
I like this idea, also because Emacs ediff / ediff3 / emerge uses it,
from what I understand under the name of 'refinement'.
>
> Pictures speak louder than words, so here are some to show what I mean:
>
> http://www.flickr.com/photos/wincent-colaiuta/sets/72157612877491482/
>
[...]
There was some discussion in this thread on how to do this, whether
with --refine / --color-chars we shoud ony highlight differences, or
whether for example use reverse (i.e. background green or background
red), or other red / other green, or perhaps bold, or perhaps
underline to highlight regions in line which differ
> - Meld: http://meld.sourceforge.net/meld_file1.png
Not extremly good example, as it uses equivalent of context diff
format (-,+,!) with added, removed and _changed_ lines, and not
unified diff format (only added / removed lines).
> Would people be interested in seeing this feature go in? [...]
+1 from me
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-23 18:41 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Daniel Barkalow, Mike Ralphson, Junio C Hamano, git
In-Reply-To: <18809.60512.654436.59819@hungover.brentg.com>
Hi,
On Fri, 23 Jan 2009, Brent Goodrick wrote:
> - Bare minimum: Add a new --no-cr option
I do not see any value of this over "--progress | tr '\r' '\n'". (The
--progress option being the natural counterpart to --no-progress,
_forcing_ the display of the progress.)
And I disagree that --no-progress would be hard to implement. Just have a
look at 7d1864c(Introduce is_bare_repository() and core.bare configuration
variable).
Basically, you'll have to
- introduce a global variable to both environment.c and cache.h,
- set it to -1 by default,
- handle a "--progress" and "--no-progress" option in git.c, setting the
global variable git_show_progress to 1 or 0, respectively,
- teach start_progress_delay() to return NULL if git_show_progress == 0,
- modify all users of start_progress*() to respect git_show_progress == 1,
which probably means to look for "isatty" in builtin-pack-objects.c and
builtin-unpack-objects.c
- add documentation to Documentation/git.txt what --progress and
--no-progress do,
- add a simple test script to t/ (maybe t/t0005-progress.sh) that tests
that --progress works -- maybe you find a clever way to test
--no-progress, too, but that would be harder, as the progress is turned
off by default for the scripts anyway...)
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] gittutorial: remove misleading note
From: Junio C Hamano @ 2009-01-23 19:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1232733749-6120-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> In the tutorial Alice initializes the repository, and Bob clones it. So
> Bob can just do a 'git pull', but Alice will need 'git pull <url>
> <branch>'.
>
> The note suggested that the branch parameter is not necessary, which is
> no longer true these days.
So we have a usability regression here. Perhaps we need to fix that
instead?
^ permalink raw reply
* Re: git blame: two "-C"s versus just a single -C
From: Sitaram Chamarty @ 2009-01-23 19:12 UTC (permalink / raw)
To: git
In-Reply-To: <slrngnjafr.iaa.sitaramc@sitaramc.homelinux.net>
On 2009-01-23, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> I seem to recall (and the docs indicate) that when you
> *copy* (not move, just copy) a function from file1.c to
> file2.c, commit, and then do a "git blame -C -C file2.c", it
> should tell you that those lines came from file1.c
>
> Is this not true? Git 1.6.1, I tried this on a dummy branch
> where I just copied a good sized function (about 45 lines)
> from one C program and dumped it at the bottom of a second
> one, and neither the gui blame nor the CLI blame show me
> that the lines came from elsewhere.
>
> What am I doing wrong?
(replying to myself...)
It works when I give it three "-C" arguments. I thought it
was supposed to be 2 though.
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Junio C Hamano @ 2009-01-23 19:23 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <8c5c35580901231040i380c6458x1a6103cd6f55c479@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
>>> The plan is to fix these limitations by extending --submodules to allow
>>> certain flags/options:
>>> a|c|r include any|checked out|registered submodules
>>> H resolve submodule HEAD to decide which tree to include
What do you mean by "decide"? If HEAD exists (iow, the submodule is
checked out), the tree of the commit recorded in the superproject's
gitlink entry is included in the result?
As I already said before, I doubt it makes much sense in the context of
the current git-archive to base the choise on checkout status.
Unless you are extending git-archive and giving it an ability to write out
the superproject index or the work tree as an archive, that is.
Just like git-grep lets you grep in the work tree files (limited to paths
that appear in the index), or grep in the contents registered to the index
when run with --cached, git-archive could make an archive out of your work
tree files or your index contents. Such an extension to git-archive may
be quite useful with or without submodules.
In such mode of operation, because you are dealing with the work tree when
run without --cached, it would make sense to say "Ah, the superproject
index wants v1.0 of the submodule, but the work tree has v2.0 of it
checked out, and we are writing out the work tree, so let's include v2.0
instead", and as a side effect of deciding which commit's tree to include
from each submodule, it naturally makes sense to exclude submodules that
are not checked out.
But otherwise I am not so sure what the point of H option would be.
^ permalink raw reply
* Re: [RFC/PATCH v3 2/3] sha1_file: prepare for adding alternates on demand
From: Johannes Schindelin @ 2009-01-23 19:54 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <8c5c35580901231035j31484249nf96e0e659b119a2b@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Lars Hjemli wrote:
> On Fri, Jan 23, 2009 at 00:43, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 22 Jan 2009, Lars Hjemli wrote:
> >> + if (!quiet)
> >> + error("object directory %s does not exist; "
> >> + "check .git/objects/info/alternates.",
> >> + ent->base);
> >
> > FWIW my concern is not at all addressed. A future user of add_alt_odb()
> > (and possibly your users in rare cases, too) can trigger the error that
> > suggests looking into the alternates. Leaving the human user puzzled.
>
> Is it the phrasing of the error message that concerns you (when
> invoked from add_alt_odb())?
>
> If so, would something like this be ok/better?
>
> >> + if (!quiet)
> >> + error("Alternate object directory %s does not exist ",
> >> + ent->base);
That would almost certainly be better.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Johannes Schindelin @ 2009-01-23 19:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <8c5c35580901231040i380c6458x1a6103cd6f55c479@mail.gmail.com>
Hi,
On Fri, 23 Jan 2009, Lars Hjemli wrote:
> On Fri, Jan 23, 2009 at 00:44, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 22 Jan 2009, Lars Hjemli wrote:
> >
> >> The new --submodules option is used to trigger inclusion of checked out
> >> submodules in the archive.
> >>
> >> The implementation currently does not verify that the submodule has
> >> been registered as 'interesting' in .git/config, neither does it
> >> resolve the currently checked out submodule HEAD but instead uses the
> >> commit SHA1 recorded in the gitlink entry to identify the submodule
> >> root tree.
> >
> > Please understand that I skipped the rest of the patch.
>
> That's too bad, I hoped on some feedback from you on the part of the
> commit message which you didn't quote:
Well, you ignored my comments, so what do you expect me to do? Be happy?
There are two issues there:
- presence of a specific commit object being present in the repository
does not necessarily mean that it is reachable by any ref, and therefore
can mean that the tree/blob objects are not reachable, because it could
be an interrupted fetch; in all of Git, we try to assume that only
reachable objects are valid objects.
- presence of a specific commit in the supermodule is a _lousy_ indicator
that the user wants to include that submodule in the archive.
Until both issues are addresse, I will not dance a little song and be
merry over this issue.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-23 20:03 UTC (permalink / raw)
To: git; +Cc: Boyd Stephen Smith Jr., Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901201450.53450.bss@iguanasuicide.net>
Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
the <branch> in the HEAD reflog and, optionally, all merge commits in
the repository. It can then resurrect the branch, pointing it at the
most recent of all candidate commits found.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Boyd Stephen Smith Jr. wrote:
> I think it could be quite nice; "undelete"-type commands are generally
> well-received by users and when run against reflogs alone, that's what the
> command is.
>
> It's useful enough to me that I'd love to see it mainlined.
So here's a version for contrib with more options and some other
tweaks.
I removed the ability to "batch resurrect" with several <name>
arguments since that would have conflicted with -b <newname>, but
otherwise the features are the same.
> In my particular case, it wasn't useful without the -m option, but I
> understand why it is not the default.
Aside from the obvious speed reasons, I don't really want to teach
people that commits "know" the branch they were on. It is a pure
coincidence if you can resurrect a topic branch from merge messages;
an equivalent merge could have gone through as a fast-forward, and
you'd never know.
contrib/git-resurrect.sh | 140 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 140 insertions(+), 0 deletions(-)
create mode 100755 contrib/git-resurrect.sh
diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
new file mode 100755
index 0000000..29bf723
--- /dev/null
+++ b/contrib/git-resurrect.sh
@@ -0,0 +1,140 @@
+#!/bin/sh
+
+USAGE="[-h] [-r] [-m] [-t] [-n] [-b <newname>] <name>"
+LONG_USAGE="git-resurrect attempts to find traces of a branch tip
+called <name>, and tries to resurrect it. Currently, the reflog is
+searched for checkout messages, and with -r also merge messages. With
+-m and -t, the history of all refs is scanned for Merge <name> into
+other/Merge <other> into <name> (respectively) commit subjects, which
+is rather slow but allows you to resurrect other people's topic
+branches."
+
+OPTIONS_SPEC="\
+git resurrect [-h] [-r] [-m] [-t] [-n] [-b <newname>] <name>
+--
+b,branch= save branch as <newname> instead of <name>
+H,try-hard same as -r -m -t
+r,reflog-merges scan for merges recorded in reflog
+m,merges scan for merges into other branches (slow)
+t,merge-targets scan for merges of other branches into <name>
+n,dry-run don't recreate the branch"
+
+. git-sh-setup
+cd_to_toplevel
+
+search_reflog () {
+ sed -n 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_reflog_merges () {
+ sed -n 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_merges () {
+ git rev-list --pretty=tformat:"%h %p:%s" --all |
+ grep "Merge branch.*'$branch'.*into" |
+ while read sha rest; do
+ parents="$(echo "$rest" | cut -d: -f1)"
+ case "$parents" in
+ *' '*' '*)
+ warn "$branch took part in octopus merge $sha"
+ warn "check manually!"
+ ;;
+ *' '*)
+ echo "$parents" | cut -d' ' -f2
+ ;;
+ esac
+ done
+}
+
+search_merge_targets () {
+ git rev-list --pretty=tformat:"%h %s" --all |
+ grep "Merge branch '[^']*' into $branch$" |
+ cut -d' ' -f1
+}
+
+dry_run=
+scan_reflog_merges=
+scan_merges=
+scan_merge_targets=
+new_name=
+
+while test "$#" != 0; do
+ case "$1" in
+ -b|--branch)
+ shift
+ new_name="$1"
+ ;;
+ -n|--dry-run)
+ dry_run=t
+ ;;
+ -m|--merges)
+ scan_merges=t
+ ;;
+ -r|--reflog_merges)
+ scan_reflog_merges=t
+ ;;
+ -t|--merge-targets)
+ scan_merge_targets=t
+ ;;
+ -H|--try-hard)
+ scan_reflog_merges=t
+ scan_merges=t
+ scan_merge_targets=t
+ ;;
+ --)
+ shift
+ break
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+test "$#" = 1 || usage
+
+branch="$1"
+test -z "$new_name" && new_name="$branch"q
+
+candidates="$(search_reflog $1)"
+if test ! -z "$scan_reflog_merges"; then
+ candidates="$candidates $(search_reflog_merges $1)"
+fi
+if test ! -z "$scan_merges"; then
+ candidates="$candidates $(search_merges $1)"
+fi
+if test ! -z "$scan_merge_targets"; then
+ candidates="$candidates $(search_merge_targets $1)"
+fi
+
+candidates="$(git rev-parse $candidates | sort -u)"
+
+if test -z "$candidates"; then
+ hint=
+ test "z$scan_merges$scan_reflog_merges$scan_merge_targets" != "zttt" \
+ && hint="(maybe try again with -H)"
+ die "no candidates for $branch found" $hint
+fi
+
+echo "** Candidates for $branch **"
+for cmt in $candidates; do
+ git --no-pager log --pretty=oneline --abbrev-commit -1 $cmt
+done
+
+newest="$(git rev-list -1 $candidates)"
+if test ! -z "$dry_run"; then
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+elif ! git rev-parse --verify --quiet $new_name >/dev/null; then
+ printf "** Restoring $new_name to "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ git branch $new_name $newest
+else
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ echo "** $new_name already exists, doing nothing"
+fi
--
1.6.1.447.gbdf1d
^ permalink raw reply related
* Re: [PATCH] Allow cloning an empty repository
From: Johannes Schindelin @ 2009-01-23 20:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090123165549.GI21473@genesis.frugalware.org>
Hi,
On Fri, 23 Jan 2009, Miklos Vajna wrote:
> On Fri, Jan 23, 2009 at 04:20:34AM +0100, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > But then, scripts have no business cloning repositories (fetching,
> > yes. But cloning?)
>
> I think portals like repo.or.cz may do it.
"git grep git.clone" in repo.git suggests that only clonecheck.sh uses it,
which is not called anywhere.
But more generally, the same should apply to such scripts as to human
users: HTTP _is_ 2nd class, and the fetch _could_ succeed later.
> Isn't setting errno (or similar variable) in the HTTP code an option?
> Then we could see why the transport failed and make a difference between
> "network error" and "no refs found".
I'd rather see the HTTP code path taken by transport.c _fail_ (i.e. die())
when there is some sort of connection error.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change octal literals to be XEmacs friendly
From: Junio C Hamano @ 2009-01-23 20:13 UTC (permalink / raw)
To: malc; +Cc: git, Alexandre Julliard
In-Reply-To: <Pine.LNX.4.64.0901232158290.2186@linmac.oyster.ru>
malc <av1474@comtv.ru> writes:
> On Fri, 23 Jan 2009, Junio C Hamano wrote:
>
>> malc@pulsesoft.com writes:
>>
>>> case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
>>> (probably because some internal type of ?\001 is char)
>>
>> And I presume the new way to spell is compatible with non XEmacs emacs?
>> It may be obvious to you, but please spell it out. Parenthesized
>> "probably" does not help building the confidence in the patch either.
>
> Fair enough.
>
> XEmacs:
> (type-of ?\1) yields character
>
> FSF Emacs:
> (type-of ?\1) yields integer
No use explaining that to me _here_. Please use that knowledge to write a
better description in an updated commit log message when sending your v2
patch.
>>> Signed-off-by: Vassili Karpov <av1474@comtv.ru>
>>
>> How are the (nameless) author of the patch malc@pulsesoft.com and Vassili
>> Karpov, the person who signed off, related?
>
> Both are my e-mail address used in ~/.gitconfig and ~/.emacs (and used
> by GNUS which was used to post the message via gmane's nntp interface)
> respectively.
Assuming that you would want to be known as Vassili, please have that name
on From: line of the message -- the patch acceptance tool takes the author
name from there.
If you can't for whatever reason use the name on From: line of the e-mail
message, you can begin the body of the message with
From: Vassili Karpov <av1474@comtv.ru>
(without indentation) and a blank line. This trick can also be used when
you are forwarding a patch somebody else wrote.
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <7vzlhhu8qo.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>>>> The plan is to fix these limitations by extending --submodules to allow
>>>> certain flags/options:
>>>> a|c|r include any|checked out|registered submodules
>>>> H resolve submodule HEAD to decide which tree to include
>
> What do you mean by "decide"? If HEAD exists (iow, the submodule is
> checked out), the tree of the commit recorded in the superproject's
> gitlink entry is included in the result?
No, when H is specified the tree of the currently checked out
submodule commit would be included (this obviously shouldn't be the
default mode of operation, hence a flag to trigger it if that is what
the user wants).
>
> As I already said before, I doubt it makes much sense in the context of
> the current git-archive to base the choise on checkout status.
>
> Unless you are extending git-archive and giving it an ability to write out
> the superproject index or the work tree as an archive, that is.
>
> Just like git-grep lets you grep in the work tree files (limited to paths
> that appear in the index), or grep in the contents registered to the index
> when run with --cached, git-archive could make an archive out of your work
> tree files or your index contents. Such an extension to git-archive may
> be quite useful with or without submodules.
Absolutely.
>
> In such mode of operation, because you are dealing with the work tree when
> run without --cached, it would make sense to say "Ah, the superproject
> index wants v1.0 of the submodule, but the work tree has v2.0 of it
> checked out, and we are writing out the work tree, so let's include v2.0
> instead", and as a side effect of deciding which commit's tree to include
> from each submodule, it naturally makes sense to exclude submodules that
> are not checked out.
>
> But otherwise I am not so sure what the point of H option would be.
I would find the H flag practical for my own usage of submodules. I
almost never modify the content of the currently checked out submodule
but I often check out a different HEAD than what is registered in the
gitlink in the superproject (typically due to testing the superproject
against different versions of the submodule). And for such a use case,
being able to create a tarball of my currently checked out state seems
useful to me.
Anyways, if we get as far as adding a --submodules option to git
archive, I believe its default mode should be to archive the
superproject HEAD state together with the gitlink'd state of each
submodule registered in .git/config instead of --submodules=c which is
what this patch implements. But I wanted to get some feedback on this
plan before trying to implement it.
--
larsh
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Junio C Hamano @ 2009-01-23 20:50 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <8c5c35580901231215q2be36abbla443975cdbb031f0@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
>> Lars Hjemli <hjemli@gmail.com> writes:
>>
>>>>> The plan is to fix these limitations by extending --submodules to allow
>>>>> certain flags/options:
>>>>> a|c|r include any|checked out|registered submodules
>>>>> H resolve submodule HEAD to decide which tree to include
>>
>> What do you mean by "decide"? If HEAD exists (iow, the submodule is
>> checked out), the tree of the commit recorded in the superproject's
>> gitlink entry is included in the result?
>
> No, when H is specified the tree of the currently checked out
> submodule commit would be included.
That makes even less sense. At that point you are mixing a tree with
random state from a work tree, and doing so only for submodules. If you
want a work tree snapshot, it should be a work tree snapshot, and should
not be labelled as a snapshot out of a tree object of the superproject.
> I would find the H flag practical for my own usage of submodules. I
> almost never modify the content of the currently checked out submodule
> but I often check out a different HEAD than what is registered in the
> gitlink in the superproject (typically due to testing the superproject
> against different versions of the submodule). And for such a use case,
> being able to create a tarball of my currently checked out state seems
> useful to me.
That would be more like an enhanced version of "git archive" that takes
the work tree state, similar to how "git grep" operates on the work tree
today.
I agree that would be useful, but I have a moderately strong suspition
that your "H" hack that includes the work tree state for checked out
submodules into a view that is primarily about the "tree" object in the
superproject, without the same "take from the work tree" semantics for
paths in the superproject, is more harmful than being helpful to the users
in the longer term. It might be simple to implement, but I do not think
its semantics can be explained sanely.
^ permalink raw reply
* Re: [PATCH] Change octal literals to be XEmacs friendly
From: malc @ 2009-01-23 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alexandre Julliard
In-Reply-To: <7vbpty1m1r.fsf@gitster.siamese.dyndns.org>
On Fri, 23 Jan 2009, Junio C Hamano wrote:
> malc@pulsesoft.com writes:
>
>> case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
>> (probably because some internal type of ?\001 is char)
>
> And I presume the new way to spell is compatible with non XEmacs emacs?
> It may be obvious to you, but please spell it out. Parenthesized
> "probably" does not help building the confidence in the patch either.
Fair enough.
XEmacs:
(type-of ?\1) yields character
FSF Emacs:
(type-of ?\1) yields integer
>
>> Signed-off-by: Vassili Karpov <av1474@comtv.ru>
>
> How are the (nameless) author of the patch malc@pulsesoft.com and Vassili
> Karpov, the person who signed off, related?
Both are my e-mail address used in ~/.gitconfig and ~/.emacs (and used
by GNUS which was used to post the message via gmane's nntp interface)
respectively.
> Next time, please spend a few minutes to see if there are active
> developers who are familiar in the area you are touching, and Cc your
> patch to ask their input.
>
> git blame -L562,+29 contrib/emacs/git.el
>
Okay.
> tells me that most of this came from 40f162b (git.el: Display file types
> and type changes., 2008-01-06) by Alexandre, so I am Cc'ing him.
>
[..snip..]
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-23 21:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1232740985-4551-1-git-send-email-trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
On Friday 2009 January 23 14:03:05 Thomas Rast wrote:
>Boyd Stephen Smith Jr. wrote:
>> I think it could be quite nice; "undelete"-type commands are generally
>> well-received by users and when run against reflogs alone, that's what the
>> command is.
>>
>> It's useful enough to me that I'd love to see it mainlined.
>
>So here's a version for contrib with more options and some other
>tweaks.
I wanted/needed the ability to ignore reflogs entirely. Use went something
like this:
1. resurrect branch from origin/pu
2. add patches, mail to list
3. # wait 24 hours
4. pull, see from logs that branch was modified, but not just my changes (or
without all of my changes).
5. delete local branch
6. Try to resurrect branch from origin/pu, get local version I just deleted.
7. delete reflog for that branch
8. Try to resurrect branch from origin/pu, get local version I merged into
master at some point.
9. Add new option.
So, I added a couple of options locally: --only-merges, so it would only look
at the first line of commit logs, ignoring my local reflogs entirely;
and --revisions, to specify arguments to pass to rev-list so it wouldn't even
see my local merges (I passed 'origin/pu origin/next').
Yeah, my usage might be abusage, but it worked for me. :)
Would you object to a patch adding a --reflog option and allowing each of the
scan options to be negated?
>I removed the ability to "batch resurrect" with several <name>
>arguments since that would have conflicted with -b <newname>, but
>otherwise the features are the same.
In my local version, which I was going to try and clean up over the weekend, I
was going to support both, by borrowing refspec syntax from fetch/push.
Specifically. Resurrecting 'js/notes' as 'pu/js/notes' would look like:
git-resurrect -H js/notes:pu/js/notes
Would you object to a patch that dropped -b in favor of the refspec syntax?
>> In my particular case, it wasn't useful without the -m option, but I
>> understand why it is not the default.
>
>Aside from the obvious speed reasons, I don't really want to teach
>people that commits "know" the branch they were on. It is a pure
>coincidence if you can resurrect a topic branch from merge messages;
>an equivalent merge could have gone through as a fast-forward, and
>you'd never know.
Yeah, agreed. I made this more clear in my local version by changing the
documentation from "scan for merges" to "scan first line of commit messages
for possible merges". It's more wordy, but it make it clear that it is
dependent on the message, and it's not tracked outside of that.
I also tend to merge topic branches with --no-ff so that I do get the merge
message, so it has a better chance of working against my repository. (I also
enjoy octopus merging when possible so the history indicates the patch sets
are separable, but maybe I'm just a little "touched" and haven't been bitten
by by an octopus yet.[1])
Not directly related to any issue you bring up:
There seems to be some needless redundancy between USAGE and OPTIONS_SPEC.
Would you object to a patch that used $USAGE inside OPTIONS_SPEC?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[1] I hear they are even more feral than penguins.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, René Scharfe
In-Reply-To: <7vljt1u4pc.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 21:50, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>> I would find the H flag practical for my own usage of submodules. I
>> almost never modify the content of the currently checked out submodule
>> but I often check out a different HEAD than what is registered in the
>> gitlink in the superproject (typically due to testing the superproject
>> against different versions of the submodule). And for such a use case,
>> being able to create a tarball of my currently checked out state seems
>> useful to me.
>
> That would be more like an enhanced version of "git archive" that takes
> the work tree state, similar to how "git grep" operates on the work tree
> today.
>
> I agree that would be useful, but I have a moderately strong suspition
> that your "H" hack that includes the work tree state for checked out
> submodules into a view that is primarily about the "tree" object in the
> superproject, without the same "take from the work tree" semantics for
> paths in the superproject, is more harmful than being helpful to the users
> in the longer term. It might be simple to implement, but I do not think
> its semantics can be explained sanely.
Ok. When someone gets the itch for 'git archive --worktree', it would
be easy enough to resurrect the idea of including the tree of the
currently checked out HEAD in selected submodules.
Do you think the other options makes any sense, i.e. is it any point
in me trying to implement this?
--
larsh
^ 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