* Re: [RFC v2] git-multimail: a replacement for post-receive-email
From: Matthieu Moy @ 2013-03-04 8:56 UTC (permalink / raw)
To: Michael Haggerty
Cc: git discussion list, Andy Parkins, Sitaram Chamarty,
Junio C Hamano, Marc Branchaud,
Ævar Arnfjörð Bjarmason, Chris Hiestand
In-Reply-To: <vpqfw0rb25c.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> A few more random thoughts (not on my personal todo-list):
One more:
When sending commit emails, it may help to ensure that the dates are
strictly monotonic, so that the thread is seen in the right order.
IIRC, "git send-email" does this by tweaking the Date: field to make
sure there is at least one second between two emails (although they may
be actually sent at the same second). It would be cool to have the same
for git multimail.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Avoid loading commits twice in log with diffs
From: Thomas Rast @ 2013-03-04 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7va9qlc690.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> Test with patch before
>> --------------------------------------------------------------------
>> 4000.2: log --raw -3000 0.50(0.43+0.06) 0.54(0.46+0.06) +7.0%***
>> 4000.3: log -p -3000 2.34(2.20+0.13) 2.37(2.22+0.13) +1.2%
>> --------------------------------------------------------------------
>> Significance hints: '.' 0.1 '*' 0.05 '**' 0.01 '***' 0.001
>
> It may be a silly question but what is a significance hint?
That's from my still-not-rerolled perf improvements series from, ahem,
ages ago:
http://thread.gmane.org/gmane.comp.version-control.git/192884
I stole the idea from R (and in fact use R to compute it). The ***
tells you that the probability of the 7% difference is attributable to
chance only with 0.1% probability, or in other words, it's highly likely
that the difference is *not* down to chance. On the other hand, note
that the p4000.3 measurements do not show a significant difference
(significance hint is absent).
The statistical background: Assume that the two series of measurements
are drawn from two normal distributions (possibly with different
mean/variance). Welch's t-test estimates the probability of the null
hypothesis that the two distributions in fact had the same mean. If you
can reject the null hypothesis, you have essentially proven that there's
*some* difference in the timing runs. (Hopefully for the better, and
hopefully _not_ caused just by CPU scaling or such.)
By the way, in the above test Jakub pointed me at the Dumbbench perl
module. I've had a look at the ideas within, and I'll try to put some
sample rejection along their lines into perf-lib. However, several
things make the module itself rather deserve the name. Most
prominently, I can only get it to print timings to stdout in a fixed
format designed for human consumption.
>> --- a/log-tree.c
>> +++ b/log-tree.c
>> @@ -715,7 +715,7 @@ static int log_tree_diff(struct rev_info *opt, struct commit *commit, struct log
>> {
>> int showed_log;
>> struct commit_list *parents;
>> - unsigned const char *sha1 = commit->object.sha1;
>> + unsigned const char *sha1 = commit->tree->object.sha1;
>
> Overall I think this goes in the right direction and I can see why
> the changes in later two hunks are correct, but I am not sure if we
> can safely assume that the caller has parsed the incoming commit and
> we have a good commit->tree here already.
>
> Right now, this static function has a single call-site in a public
> function log_tree_commit(), whose existing callers may all pass an
> already parsed commit, but I feel somewhat uneasy to do the above
> without some mechanism in place (either parse it here or in the
> caller if unparsed, or document that log_tree_commit() must be
> called with a parsed commit and perhaps add an assert there) to
> ensure that the invariant is not broken in the future.
In that case I'll reroll with the parsing -- it will have about the same
cost as the assertion, since it'll just check ->object.parsed and
return.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-p4: Importing a Git repository into Perforce without rebasing
From: Enrico Weigelt @ 2013-03-04 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <CABYiQpnv6U2BVDB0v2Q3ia1x9FmYhNERDpE41TjE2qD5Y9L50A@mail.gmail.com>
Hi,
<snip>
perhaps you should give Perfoce's git-bridge a try.
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Mobile: +49 (151) 27565287
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Configurable .gitignore filename?
From: Jari Pennanen @ 2013-03-04 11:58 UTC (permalink / raw)
To: git
If project or directory belongs to more than one GIT_DIR then some of
the GIT_DIR's may need a different .gitignore files, it would be
useful if one could define it independently, e.g. in GIT_DIR/config:
[core]
ignorefilename = .gitalternateignore
Has anyone considered making the .gitignore filename configurable? It
could be in a config file or env variable, but either way it would be
handy to be configurable. I'm not familiar with git's structure, but
if ignoring is only used in git-add then I suppose I could make own
git-add script if this is not implemented in core git.
I intend to use GIT as a rsync replica (or Dropbox replica) cause it
suits it better than rsync, since GIT doesn't have to check all files
each time I sync (and GIT can contain versions / backups, works better
on Windows and has a simpler needs for the server), more about why I
need this: https://groups.google.com/forum/#!topic/git-users/E-Au9P0A6NA/discussion%5B1-25-false%5D
- Jari
^ permalink raw reply
* Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached
From: Duy Nguyen @ 2013-03-04 12:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <7vy5e49l3i.fsf@alter.siamese.dyndns.org>
On Mon, Mar 4, 2013 at 5:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> When a remote ref or a tag is checked out, HEAD is automatically
>> detached. There is no user friendly way to find out what ref is
>> checked out in this case. This patch digs in reflog for this
>> information and shows "Detached from origin/master" or "Detached from
>> v1.8.0" instead of "Currently not on any branch".
>
> "Detached from" is a nice attempt to compromise in the phrasing.
>
> We usually say you detach HEAD at v1.8.0, but what is shown is what
> started from such a state but then the user may have built more
> history on top of it and may no longer be at v1.8.0, so obviously we
> do not want to say "Detached at". We are in a "detached at v1.8.0
> and then possibly built one or more commits on top" state (would it
> be helpful to differentiate the "nothing built on top" and "some
> commits have been built on top" cases, I wonder).
Hmm.. never thought of that subtlety. Differentiating should be
possible. I'm just not sure if it would be helpful. Comments people,
do or not do?
> Also I wonder if you could do a bit more to help the users who do:
>
> $ git checkout $(git merge-base HEAD nd/branch-show-rebase-bisect-state)
>
> aka
>
> $ git checkout ...nd/branch-show-rebase-bisect-state
>
> and then do one or more commits on top.
>
> Instead of punting to "Currently not on any branch", would it help
> to show the place you first detached at, so that the user can then
> grab that commit object name and run
>
> $ git log --oneline $that_commit..
>
> or something?
$that_commit would be HEAD@{-1} right? Should that be used instead of
grabbing random SHA-1 shown in git-status?
>> +static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,
>
> Can't this be done by generalizing grab_nth_branch_switch() and then
> exposing it as part of the general API?
We could share the code, yes. Initially I wanted something that
resolves "@{-1}" and gives me the reflog entry. Maybe we could add a
function to do that.
> I also feel uneasy about two issues this and the previous change
I assume "previous change" is 1/5, reflog format change.
> 2) The previous one records this sequence in a funny way:
>
> : start from branch A
> git checkout B
> git checkout C
>
> The resulting reflog entries result in
>
> checkout: moving from A to refs/heads/B
> checkout: moving from B to refs/heads/C
>
> even though existing code and tools are expecting to read
>
> checkout: moving from A to B
> checkout: moving from B to C
It does not record exactly user input, but the "to" part is basically
extended sha-1 and I don't think current tools parse them manually.
Instead just they should just pass them to git-rev-parse to do the
job. So this change is not really bad. But again the recent '!'
incident in attr.c shows that I know nothing about real world usage.
We could do dwim when parsing the reflog, which introduces no changes
in reflog format.
> By the way, even though the title of this patch is "status: show the
> ref that is checked out, even if it's detached", a quick check with
>
> $ cd ../linux-3.0
> $ git describe
> v3.8-rc7
> $ ../git.git/git-checkout v3.8-rc7
> $ tail -n 1 .git/logs/HEAD | sed -e 's/.*checkout/checkout/'
> checkout: moving from master to refs/tags/v3.8-rc7
> $ ../git.git/git-status | head -n 1
> # Not currently on any branch.
> $ ../git.git/git-branch -v
> * (no branch) 836dc9e Linux 3.8-rc7
> master 836dc9e Linux 3.8-rc7
>
> does not seem to give me anything more helpful.
Yeah. I blame myself for copying from interpret_nth_prior_checkout()
without full understanding, and git's poor documentation (there's no
description about for_each_recent_reflog_ent, and that the caller is
supposed to call for_each_reflog_ent in some case; but I think this
convention is unintuitive, for_each_recent_reflog_ent should do that
itself)
--
Duy
^ permalink raw reply
* Re: Configurable .gitignore filename?
From: Matthieu Moy @ 2013-03-04 13:53 UTC (permalink / raw)
To: Jari Pennanen; +Cc: git
In-Reply-To: <CACoicv+Hq=d5fJ7PXYdyvOdWmc3-GbFrsAf2Ze7dnQTzjExXnw@mail.gmail.com>
Jari Pennanen <jari.pennanen@gmail.com> writes:
> If project or directory belongs to more than one GIT_DIR then some of
> the GIT_DIR's may need a different .gitignore files, it would be
> useful if one could define it independently, e.g. in GIT_DIR/config:
>
> [core]
> ignorefilename = .gitalternateignore
There is already core.excludesfile, which does not replace the usual
.gitignore but comes in addition. The common use is a user-wide ignore
file, not a per-directory one.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Configurable .gitignore filename?
From: Jari Pennanen @ 2013-03-04 15:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqzjyjp8y0.fsf@grenoble-inp.fr>
2013/3/4 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> There is already core.excludesfile, which does not replace the usual
> .gitignore but comes in addition. The common use is a user-wide ignore
> file, not a per-directory one.
I'm actually aware of that. Problem is the normal .gitignore files
must *not* be used in the second GIT_DIR at all, in my case it's for
syncing so I need to sync almost all files (including stuff inside
.gitignore), though I'd still like to retain some ignore files for
second GIT_DIR, e.g. like in rsync the .rsync-filter file.
^ permalink raw reply
* Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached
From: Junio C Hamano @ 2013-03-04 15:49 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <CACsJy8A+gw9oJYrJqa-b8noKM7qJTkZEd7ovmxqR68i6miCatA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>> Instead of punting to "Currently not on any branch", would it help
>> to show the place you first detached at, so that the user can then
>> grab that commit object name and run
>>
>> $ git log --oneline $that_commit..
>>
>> or something?
>
> $that_commit would be HEAD@{-1} right? Should that be used instead of
> grabbing random SHA-1 shown in git-status?
You can say "git checkout @{-1}" to go back. That is the commit you
came _from_.
But I think what you were computing for $that_commit was different.
It's "the ref that is checked out, even if it's detached".
After doing:
: start from anywhere
git checkout master ;# on master
git checkout branch~4 ;# detach at that commit
... hack hack hack ...
git commit; git commit
your @{-1} is 'master'; "the ref that is checked out, even if its'
detached" is 'branch~4', and that is what you want as $that_commit
in the example. That shows your _progress_, which has no relation
with 'master' that is @{-1}.
^ permalink raw reply
* auto merge bug
From: David Krmpotic @ 2013-03-04 16:46 UTC (permalink / raw)
To: git
Hi!
We started working on a .NET app and the XML project file (.csproj)
got corrupted (a few closing tag missing).
79 <Compile Include="SlovaricaForm.Designer.cs">
80 <DependentUpon>SlovaricaForm.cs</DependentUpon>
81 + <Compile Include="WebCamForm.cs">
82 + <SubType>Form</SubType>
83 + </Compile>
84 + <Compile Include="WebCamForm.Designer.cs">
85 + <DependentUpon>WebCamForm.cs</DependentUpon>
86 </Compile>
between lines 80 and 81 there should be </Compile>
similarly:
121 </EmbeddedResource>
122 <EmbeddedResource Include="SlovaricaForm.resx">
123 <DependentUpon>SlovaricaForm.cs</DependentUpon>
124 + <EmbeddedResource Include="WebCamForm.resx">
125 + <DependentUpon>WebCamForm.cs</DependentUpon>
126 </EmbeddedResource>
127 <EmbeddedResource Include="WordsSelectForm.resx">
128 <DependentUpon>WordsSelectForm.cs</DependentUpon>
between 123 and 124 there is </EmbeddedResource> missing.
The problematic commit is here:
https://github.com/davidhq/logo_x/commit/e3e5fa4b60b7939999b2a8c44330312755b72f93
it has two parents: ae2a364 and bd1a059
on both parents the project compiles in Visual Studio because
Logo.csproj is not corrupted.
How to reproduce and see that really there were no conflicts and the
file became corrupted:
C:\temp> git clone git@github.com:davidhq/logo_x.git
C:\temp\logo_x [master]> git checkout ae2a364
Note: checking out 'ae2a364'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at ae2a364... general handler for letters
C:\temp\logo_x [(ae2a364...)]> git merge bd1a059
Auto-merging Logo/Logo.csproj
Merge made by the 'recursive' strategy.
Logo/Logo.csproj | 7 ++
Logo/WebCamForm.Designer.cs | 88 +++++++++++++++++++
Logo/WebCamForm.cs | 209 ++++++++++++++++++++++++++++++++++++++++++++
Logo/WebCamForm.resx | 120 +++++++++++++++++++++++++
Logo/WordsForm.Designer.cs | 1 +
Logo/WordsForm.cs | 7 ++
6 files changed, 432 insertions(+)
create mode 100644 Logo/WebCamForm.Designer.cs
create mode 100644 Logo/WebCamForm.cs
create mode 100644 Logo/WebCamForm.resx
Now check Logo.csproj and observe line 81 (it should read </Compile>
If I add both missing closing tags the project compiles again.
Please investigate and thank you!
PS: on Windows I have version 1.8.0.msysgit.0 of git and on Mac I'm
not sure now, it's a bit older, but the same problem happens.
David
^ permalink raw reply
* Re: [PATCH] Allow combined diff to ignore white-spaces
From: Antoine Pelisse @ 2013-03-04 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v38wdc4ei.fsf@alter.siamese.dyndns.org>
>> That should be reviewed carefully as I'm not exactly sure that does make
>> sense with the way combined-diff works.
>> Still it seems natural to me to be able to remove the space in combined
>> diff as we do with normal diff. Especially as I unfortunately have to
>> deal with many space + feature merges that are very hard to analyze/handle
>> if space differences can't be hidden.
>
> Assuming "That" at the beginning of the off-line comment refers to
> "this patch", I actually I do not think this patch needs to be
> reviewed carefully at all.
I actually meant: "is that patch enough or is there anything I
missed". Considering your answer, it looks like I did ;)
> An example. After collecting pairwise diffs between the shared
> postimage and individual parents, we align the hunks and coalesce
> "identical" preimage lines to form shared "-" (removed) lines. I
> think that step is done with byte-for-byte comparison. If the
> postimage removes a line from one parent and a corresponding line
> from another parent, and if these corresponding lines in the parents
> differ only by whitespaces in a way the user told us to ignore with
> -b/-w/etc., you would need to tweak the logic to coalesce
> corresponding "lost" lines in the append_lost() function. Otherwise,
> you will see two " -" and "- " lines that remove these corresponding
> lines from the parents that are identical when you ignore
> whitespaces.
That is the part I missed, and it's nicely explained.
> You should add some tests; it would help you think about these
> issues through.
I will definitely add some tests.
> For example, in this history:
>
> git init
> seq 11 >ten
> git add ten
> git commit -m initial
>
> seq 10 | sed -e 's/6/6 six/' -e 's/2/2 two/' >ten
> echo 11 >>ten
> git commit -m ten -a
>
> git checkout -b side HEAD^
> seq 10 | sed -e 's/^/ /' | sed -e 's/2/2 dos/' >ten
> echo 11 >>ten
> git commit -m indent -a
>
> git merge master
>
> seq 10 | sed -e 's/5/5 go/' -e 's/2/2 dois/' >ten
> git commit -m merged -a
>
> one side indents the original and tweaks some lines, while the other
> side tweaks some other lines without reindenting. Most notably, the
> fifth line on one side is "5" while on the other side is " 5", and
> this line is rewritten to "5 go" in the final. The lost lines are
> not coalesced to a single "-- 5" (nor "-- 5") but shows that two
> preimages were different only by whitespaces. Compare that with
> what happens to the final line "11" that gets lost in the result.
It feels incorrect to me to coalsesce "- 5" and "- 5" as it might
look incorrect to the user. But still the idea is appealing. I have an
implementation for that that requires more testing.
Using the exact example you gave, and running the latest next, I have
this output, where 11 is not coalesced.
Is that a bug ?
diff --cc ten
index d213a99,ed40ab2..37c2af2
--- a/ten
+++ b/ten
@@@ -1,11 -1,11 +1,10 @@@
- 1
- 2 dos
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
+ 1
-2 two
++2 dois
+ 3
+ 4
-5
-6 six
++5 go
++6
+ 7
+ 8
+ 9
+ 10
-11
^ permalink raw reply
* "git commit" fails due to spurious file in index
From: Robert Irelan @ 2013-03-04 18:15 UTC (permalink / raw)
To: git@vger.kernel.org
Hello all:
This is my first time posting to this mailing list, but it appears to
me, through a Google search, that this is where you go to report what
might be bugs. I'm not sure if this is a bug or not, but it is
mysterious to me.
My git repository has this directory structure (I don't know if the file
names are necessary or not; only the leaf directories contain files):
$ tree -ad -I.git
.
└── admin_scripts
├── integchk
│ ├── 2012
│ └── 2014
├── jrnadmin
│ ├── 2012
│ └── 2014
└── logarchiver
├── 2012
└── 2014
10 directories
The last commit in this repo was a rearrangement of the hierarchy
carried out using `git mv`. Before, the directory structure went
`admin_scripts/version/script_name` instead of
`admin_scripts/script_name/version`.
Now I'm attempting to some new files that I've already created into the
repository, so that the repo now looks like this (`setup/2012`
contains files, while `setup/2014` is empty):
$ tree -ad -I.git
.
└── admin_scripts
├── integchk
│ ├── 2012
│ └── 2014
├── jrnadmin
│ ├── 2012
│ └── 2014
├── logarchiver
│ ├── 2012
│ └── 2014
└── setup
├── 2012
└── 2014
13 directories
Now, when I run 'git add admin_script/setup' to add the new directory to
the repo and then try to commit, I receive the following message:
$ git commit
mv: cannot stat `admin_scripts/setup/2012/setup': No such file or directory
The error message is correct in that `admin_scripts/setup/2012/setup`
does not exist, either as a file or as a directory. However, I'm not
attempting to add this path at all. Using grep, I've confirmed that the
only place this path appears in any of my files is in `.git/index`.
Also, I can commit to other places in the repository without triggering
any error. In addition, I can clone the repository to other locations
and apply the problematic commit manually. This is how I've worked
around the problem for now, and I've moved the repository that's
exhibiting problems to another directory and started work on the cloned
copy.
Why is this spurious path appearing in the index? Is it a bug, or a
symptom that my repo has been somehow corrupted? Any help would be
greatly appreciated.
Robert Irelan | Server Systems | Epic | (608) 271-9000
^ permalink raw reply
* Re: [PATCH] Allow combined diff to ignore white-spaces
From: Junio C Hamano @ 2013-03-04 18:36 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <CALWbr2z0eok-VOQX7DDZafevQUi7asCv_tD8=y6XA2PVYf52AQ@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> It feels incorrect to me to coalsesce "- 5" and "- 5" as it might
> look incorrect to the user. But still the idea is appealing.
The users already need to see that when reading a regular patch with
one or more context lines and -b/-w/etc., anyway. The context lines
are made into context only because whitespace differences were
ignored, and in the regular unified patch format we can show only
one version, either from preimage or from postimage, and have to
pick one. Coalescing "- 5" and "- 5" into "--5" or "-- 5" by
picking one or the other is the same thing, no?
> Using the exact example you gave, and running the latest next, I have
> this output, where 11 is not coalesced.
> Is that a bug ?
It could be tickling a corner case because the removal is at the end
of the file. Perhaps adding 12 that is all common across three
versions and see what happens?
^ permalink raw reply
* Re: [BUG/TEST 0/2] bugs with cherry-pick renames
From: Stephen Boyd @ 2013-03-04 18:48 UTC (permalink / raw)
To: git
In-Reply-To: <1360643262-1472-1-git-send-email-sboyd@codeaurora.org>
On 02/11/13 20:27, Stephen Boyd wrote:
> I ran into these bugs the other day and didn't have time to
> investigate further. So I wrote test cases for them instead.
>
> Stephen Boyd (2):
> t3501: Expose bug with cherry-pick into dirty trees w/ renames
> t3501: Expose addinfo_cache error message in cherry-pick
>
> t/t3501-revert-cherry-pick.sh | 60 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
>
Any comments? Anyone else running into these bugs?
^ permalink raw reply
* Re: [PATCH] Allow combined diff to ignore white-spaces
From: Antoine Pelisse @ 2013-03-04 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5e3vwos.fsf@alter.siamese.dyndns.org>
On Mon, Mar 4, 2013 at 7:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> It feels incorrect to me to coalsesce "- 5" and "- 5" as it might
>> look incorrect to the user. But still the idea is appealing.
>
> The users already need to see that when reading a regular patch with
> one or more context lines and -b/-w/etc., anyway. The context lines
> are made into context only because whitespace differences were
> ignored, and in the regular unified patch format we can show only
> one version, either from preimage or from postimage, and have to
> pick one. Coalescing "- 5" and "- 5" into "--5" or "-- 5" by
> picking one or the other is the same thing, no?
That's all I needed to be convinced. I obviously don't care which one we pick.
>> Using the exact example you gave, and running the latest next, I have
>> this output, where 11 is not coalesced.
>> Is that a bug ?
>
> It could be tickling a corner case because the removal is at the end
> of the file. Perhaps adding 12 that is all common across three
> versions and see what happens?
Doesn't make a difference. Still have "- 11" and " -11".
I will try to have a look at it.
^ permalink raw reply
* "git rebase" loses the additional changes in "evil" merges
From: Dale R. Worley @ 2013-03-04 20:58 UTC (permalink / raw)
To: git
(git version 1.7.7.6)
I've been learning how to use Git. While exploring "git rebase", I've
discovered that if the branch being rebased contains an "evil" merge,
that is, a merge which contains changes that are in addition to the
changes in any of the parent commits, the rebase operation will
silenty lose those additional changes.
I believe that this is a serious bug.
The problem is not that Git does not propagate the additional changes
(although I'd like it to do so), the problem is that the rebase
*silently loses* changes in the code. It would be acceptable if Git
detected the evil merge, notified me of it, and forced me to manually
re-do it in order to finish the rebase.
Throughout the Git design (as in other SCMs), care has been taken to
not lose changes that the user has introduced. In this situation,
that principle is violated.
I have a script that demonstrates this failure, if that would be
useful for testing purposes.
Dale
^ permalink raw reply
* Re: "git commit" fails due to spurious file in index
From: Thomas Rast @ 2013-03-04 20:58 UTC (permalink / raw)
To: Robert Irelan; +Cc: git@vger.kernel.org
In-Reply-To: <2D9BD788B02ABA478C57929170AF952B7622B5@EXCH-MBX-3.epic.com>
Robert Irelan <rirelan@epic.com> writes:
> Now, when I run 'git add admin_script/setup' to add the new directory to
> the repo and then try to commit, I receive the following message:
>
> $ git commit
> mv: cannot stat `admin_scripts/setup/2012/setup': No such file or directory
>
> The error message is correct in that `admin_scripts/setup/2012/setup`
> does not exist, either as a file or as a directory. However, I'm not
> attempting to add this path at all. Using grep, I've confirmed that the
> only place this path appears in any of my files is in `.git/index`.
To me that sounds like the message comes from a commit hook. Can you
check if you have anything in .git/hooks/, especially pre-commit?
There really isn't any other good reason why 'git commit' would call
'mv' (plain mv, not git!).
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: "git rebase" loses the additional changes in "evil" merges
From: Junio C Hamano @ 2013-03-04 21:18 UTC (permalink / raw)
To: Dale R. Worley; +Cc: git
In-Reply-To: <201303042058.r24KwwEx012408@freeze.ariadne.com>
worley@alum.mit.edu (Dale R. Worley) writes:
> (git version 1.7.7.6)
>
> I've been learning how to use Git. While exploring "git rebase", I've
> discovered that if the branch being rebased contains an "evil" merge,
> that is, a merge which contains changes that are in addition to the
> changes in any of the parent commits, the rebase operation will
> silenty lose those additional changes.
I think this is to be expected for "git rebase", as it does not even
look at merges. It is a way to find non-merge commits that haven't
been applied yet, and apply them to the upstream to create a new
linear history.
^ permalink raw reply
* [PATCH v6] submodule: add 'deinit' command
From: Jens Lehmann @ 2013-03-04 21:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, Git Mailing List, Heiko Voigt, Michael J Gruber,
Marc Branchaud, W. Trevor King
In-Reply-To: <51227EFE.6030908@web.de>
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).
Help those users by providing a 'deinit' command. This removes the
whole submodule.<name> section from .git/config (either for the given
submodule(s) or for all those which have been initialized if '.' is used)
together with their work tree. Fail if the current work tree contains
modifications (unless forced), but don't complain when either the work
tree is already removed or no settings are found in .git/config.
Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him. Also add the deinit subcommand
to the completion list.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 18.02.2013 20:20, schrieb Jens Lehmann:
> Am 17.02.2013 23:32, schrieb Junio C Hamano:
>> It seems that this "warn if user told us to deinitialize a submodule
>> that hasn't been initialized" is from the very initial round of this
>> series, and not something other people asked for during the review.
>> If somebody did
>>
>> git submodule deinit foo bar
>>
>> and then later said:
>>
>> git submodule deinit foo
>>
>> would it a mistake that the user wants to be warned about?
>>
>> Perhaps the user did not mean to deinitialize foo (e.g. wanted to
>> *initialize* foo instead, or wanted to deinitialize *foz* instead)
>> and that is worth warning about? I am not sure, but I have a
>> feeling that we can do without this check.
>
> Hmm, if you would replace "submodule deinit" with "rm" in the above
> example, the "rm" would not only warn but error out the second time.
> But on the other hand doing a "git submodule init" again on already
> initialized submodules will silently do nothing, which seems to be
> the better analogy here. So yes, it looks like we can do without.
>
> Ok, unless someone speaks up and argues in favor of this message
> I'll remove it in v6.
Nobody spoke up, so here we go.
Changes since v5:
- No warning message when the url setting is not found
- Reword second commit message paragraph accordingly
- Use 'git config --get-regexp "submodule\.example\."' in tests
- Fix a copied comment still talking about "init"
Hopefully this is the final version ;-)
Documentation/git-rm.txt | 4 ++
Documentation/git-submodule.txt | 18 +++++-
contrib/completion/git-completion.bash | 2 +-
git-submodule.sh | 77 ++++++++++++++++++++++++-
t/t7400-submodule-basic.sh | 100 +++++++++++++++++++++++++++++++++
5 files changed, 198 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 92bac27..1d876c2 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
Ignored files are deemed expendable and won't stop a submodule's work
tree from being removed.
+If you only want to remove the local checkout of a submodule from your
+work tree without committing the removal,
+use linkgit:git-submodule[1] `deinit` instead.
+
EXAMPLES
--------
`git rm Documentation/\*.txt`::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index c99d795..74d5bdc 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference <repository>]
[--merge] [--recursive] [--] [<path>...]
@@ -135,6 +136,19 @@ init::
the explicit 'init' step if you do not intend to customize
any submodule locations.
+deinit::
+ Unregister the given submodules, i.e. remove the whole
+ `submodule.$name` section from .git/config together with their work
+ tree. Further calls to `git submodule update`, `git submodule foreach`
+ and `git submodule sync` will skip any unregistered submodules until
+ they are initialized again, so use this command if you don't want to
+ have a local checkout of the submodule in your work tree anymore. If
+ you really want to remove a submodule from the repository and commit
+ that use linkgit:git-rm[1] instead.
++
+If `--force` is specified, the submodule's work tree will be removed even if
+it contains local modifications.
+
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
@@ -214,8 +228,10 @@ OPTIONS
-f::
--force::
- This option is only valid for add and update commands.
+ This option is only valid for add, deinit and update commands.
When running add, allow adding an otherwise ignored submodule path.
+ When running deinit the submodule work trees will be removed even if
+ they contain local changes.
When running update, throw away local changes in submodules when
switching to a different commit; and always run a checkout operation
in the submodule, even if the commit listed in the index of the
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b62bec0..6ab5752 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2413,7 +2413,7 @@ _git_submodule ()
{
__git_has_doubledash && return
- local subcommands="add status init update summary foreach sync"
+ local subcommands="add status init deinit update summary foreach sync"
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
case "$cur" in
--*)
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..44f70c4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
+ or: $dashless [--quiet] deinit [-f|--force] [--] <path>...
or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
@@ -547,6 +548,80 @@ cmd_init()
}
#
+# Unregister submodules from .git/config and remove their work tree
+#
+# $@ = requested paths (use '.' to deinit all submodules)
+#
+cmd_deinit()
+{
+ # parse $args after "submodule ... deinit".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -f|--force)
+ force=$1
+ ;;
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
+ if test $# = 0
+ then
+ die "$(eval_gettext "Use '.' if you really want to deinitialize all submodules")"
+ fi
+
+ module_list "$@" |
+ while read mode sha1 stage sm_path
+ do
+ die_if_unmatched "$mode"
+ name=$(module_name "$sm_path") || exit
+
+ # Remove the submodule work tree (unless the user already did it)
+ if test -d "$sm_path"
+ then
+ # Protect submodules containing a .git directory
+ if test -d "$sm_path/.git"
+ then
+ echo >&2 "$(eval_gettext "Submodule work tree '\$sm_path' contains a .git directory")"
+ die "$(eval_gettext "(use 'rm -rf' if you really want to remove it including all of its history)")"
+ fi
+
+ if test -z "$force"
+ then
+ git rm -n "$sm_path" ||
+ die "$(eval_gettext "Submodule work tree '\$sm_path' contains local modifications; use '-f' to discard them")"
+ fi
+ rm -rf "$sm_path" || say "$(eval_gettext "Could not remove submodule work tree '\$sm_path'")"
+ fi
+
+ mkdir "$sm_path" || say "$(eval_gettext "Could not create empty submodule directory '\$sm_path'")"
+
+ # Remove the .git/config entries (unless the user already did it)
+ if test -n "$(git config --get-regexp submodule."$name\.")"
+ then
+ # Remove the whole section so we have a clean state when
+ # the user later decides to init this submodule again
+ url=$(git config submodule."$name".url)
+ git config --remove-section submodule."$name" 2>/dev/null &&
+ say "$(eval_gettext "Submodule '\$name' (\$url) unregistered for path '\$sm_path'")"
+ fi
+ done
+}
+
+#
# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
@@ -1157,7 +1232,7 @@ cmd_sync()
while test $# != 0 && test -z "$command"
do
case "$1" in
- add | foreach | init | update | status | summary | sync)
+ add | foreach | init | deinit | update | status | summary | sync)
command=$1
;;
-q|--quiet)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 2683cba..5030f1f 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -757,4 +757,104 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
)
'
+test_expect_success 'set up a second submodule' '
+ git submodule add ./init2 example2 &&
+ git commit -m "submodule example2 added"
+'
+
+test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ git submodule deinit init &&
+ test -z "$(git config --get-regexp "submodule\.example\.")" &&
+ test -n "$(git config --get-regexp "submodule\.example2\.")" &&
+ test -f example2/.git &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit . deinits all initialized submodules' '
+ git submodule update --init &&
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ test_must_fail git submodule deinit &&
+ git submodule deinit . &&
+ test -z "$(git config --get-regexp "submodule\.example\.")" &&
+ test -z "$(git config --get-regexp "submodule\.example2\.")" &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit deinits a submodule when its work tree is missing or empty' '
+ git submodule update --init &&
+ rm -rf init example2/* example2/.git &&
+ git submodule deinit init example2 &&
+ test -z "$(git config --get-regexp "submodule\.example\.")" &&
+ test -z "$(git config --get-regexp "submodule\.example2\.")" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule contains modifications unless forced' '
+ git submodule update --init &&
+ echo X >>init/s &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config --get-regexp "submodule\.example\.")" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config --get-regexp "submodule\.example\.")" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule contains untracked files unless forced' '
+ git submodule update --init &&
+ echo X >>init/untracked &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config --get-regexp "submodule\.example\.")" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config --get-regexp "submodule\.example\.")" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule HEAD does not match unless forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ git checkout HEAD^
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config --get-regexp "submodule\.example\.")" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config --get-regexp "submodule\.example\.")" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit is silent when used on an uninitialized submodule' '
+ git submodule update --init &&
+ git submodule deinit init >actual &&
+ test_i18ngrep "Submodule .example. (.*) unregistered for path .init" actual &&
+ git submodule deinit init >actual &&
+ test_i18ngrep ! "Submodule .example. (.*) unregistered for path .init" actual &&
+ git submodule deinit . >actual &&
+ test_i18ngrep ! "Submodule .example. (.*) unregistered for path .init" actual &&
+ test_i18ngrep "Submodule .example2. (.*) unregistered for path .example2" actual &&
+ git submodule deinit . >actual &&
+ test_i18ngrep ! "Submodule .example. (.*) unregistered for path .init" actual &&
+ test_i18ngrep ! "Submodule .example2. (.*) unregistered for path .example2" actual &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit fails when submodule has a .git directory even when forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ rm .git &&
+ cp -R ../.git/modules/example .git &&
+ GIT_WORK_TREE=. git config --unset core.worktree
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test_must_fail git submodule deinit -f init &&
+ test -d init/.git &&
+ test -n "$(git config --get-regexp "submodule\.example\.")"
+'
+
test_done
--
1.8.2.rc2.5.geb8e692
^ permalink raw reply related
* Re: "git rebase" loses the additional changes in "evil" merges
From: Thomas Rast @ 2013-03-04 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dale R. Worley, git
In-Reply-To: <7vtxoqx3s1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> worley@alum.mit.edu (Dale R. Worley) writes:
>
>> (git version 1.7.7.6)
>>
>> I've been learning how to use Git. While exploring "git rebase", I've
>> discovered that if the branch being rebased contains an "evil" merge,
>> that is, a merge which contains changes that are in addition to the
>> changes in any of the parent commits, the rebase operation will
>> silenty lose those additional changes.
>
> I think this is to be expected for "git rebase", as it does not even
> look at merges. It is a way to find non-merge commits that haven't
> been applied yet, and apply them to the upstream to create a new
> linear history.
I can see the problem with --preserve-merges though. It will actually
just *redo* the merge; the name is wrong in the sense that it undertakes
nothing to preserve whatever evilness was in it.
I suppose in theory it could first redo the merge on the original
parents, and diff against the existing merge; that would be the evilness
component. Then it could attempt to apply the same evilness on the new
merge.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: "git rebase" loses the additional changes in "evil" merges
From: Junio C Hamano @ 2013-03-04 21:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: Dale R. Worley, git
In-Reply-To: <87sj4aoo3s.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> worley@alum.mit.edu (Dale R. Worley) writes:
>>
>>> (git version 1.7.7.6)
>>>
>>> I've been learning how to use Git. While exploring "git rebase", I've
>>> discovered that if the branch being rebased contains an "evil" merge,
>>> that is, a merge which contains changes that are in addition to the
>>> changes in any of the parent commits, the rebase operation will
>>> silenty lose those additional changes.
>>
>> I think this is to be expected for "git rebase", as it does not even
>> look at merges. It is a way to find non-merge commits that haven't
>> been applied yet, and apply them to the upstream to create a new
>> linear history.
>
> I can see the problem with --preserve-merges though. It will actually
> just *redo* the merge; the name is wrong in the sense that it undertakes
> nothing to preserve whatever evilness was in it.
With or without evil, preserve-merges have other issues to make me
not to trust it. Which side branches to take literally (i.e. just
merge again) vs which side branches to also rebase (i.e. rebuild the
history and then merge).
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.
^ permalink raw reply
* Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From: Jens Lehmann @ 2013-03-04 22:15 UTC (permalink / raw)
To: Eric Cousineau; +Cc: git
In-Reply-To: <CA+aSAWuoxZkSnRybhefnFr9ngs3tHmt6hAH4o0ebjYKvjJ-vpw@mail.gmail.com>
Please don't attach your patches, see Documentation/SubmittingPatches on
how to post patches to this list.
Am 04.03.2013 09:41, schrieb Eric Cousineau:
> In this patch, foreach --recursive acts depth-first, much like the default
> behavior described in the patch by Imram Yousuf in this
> post <http://marc.info/?l=git&m=121066084508631&w=2>.
> Changes were made so that the submodule "Entering ..." message was right
> next to the output generated by the command too.
> It also adds the --parent option for executing the command in the
> supermodule as well.
>From reading the linked pages I assume a valid use case you have is:
git submodule foreach --recursive 'git add -A && git commit ...'
This will currently not work because the depth first algorithm of foreach
will execute the command /before/ recursing deeper. You'd need it to
execute the command /after/ returning from the deeper level (which is what
your patch seems to be about).
> I began by adding a --depth option, to preserve the original --recursive
> behavior, and the --parent option, and trying to get that to work. However,
> I pretty much confused myself for a while trying to straighten that out, so
> I just ended up modifying the --recursive behavior.
> If the --recursive behavior should be preserved, I could add the --depth
> option back and only have --parent affect non-recursive and --depth
> recursive behavior.
I would rather not change default behavior without having a *very* good
reason to do so (and I'm not sure what you need the --depth option for).
What we currently get from your example is:
Entering 'a'
Entering 'a/b'
Entering 'a/b/d'
Entering 'a/c'
Entering 'b'
Entering 'b/d'
Entering 'c'
Entering 'd'
Me thinks this is what most users would expect of a recursion, enter each
level before descending into the next.
For your use case you'd need to have:
Entering 'a/b/d'
Entering 'a/b'
Entering 'a/c'
Entering 'a'
Entering 'b/d'
Entering 'b'
Entering 'c'
Entering 'd'
(Please note that this is still depth-first)
I won't object to adding an option to foreach that will execute the command
after recursing (but I'm not convinced --parent is a very good name for that).
> I had kind-of implemented this behavior with aliases / bash functions
> (posted to pastebin <http://pastebin.com/yLHe9XWy>
> , spurned by a
> question I asked in StackOverflow <http://stackoverflow.com/q/14846967/170413>),
> however I would always run into issues with escaping characters when
> passing from the bash functions to git aliases (i.e., putting "'ello" as an
> test commit message). I also tried out mb14's method from the StackOverflow
> post, but I ran into the same issues.
> Figured the best way to avoid that was to cut out the extra layers.
It seems to be really hard to do what you have in mind with shell commands
or aliases, which is a good point for adding such an option to foreach. But
I don't see a reason why we would want to change the current default, which
is what your RFC proposes.
^ permalink raw reply
* Re: Subtree in Git
From: Paul Campbell @ 2013-03-04 22:33 UTC (permalink / raw)
To: David Michael Barr; +Cc: Kindjal, git
In-Reply-To: <CALeLG_=Yy0TkY-vY8AE9CtXhs4zF8kjdQBNdp+N4yhFmHM79RA@mail.gmail.com>
On Sat, Mar 2, 2013 at 5:43 PM, Paul Campbell <pcampbell@kemitix.net> wrote:
> On Sat, Mar 2, 2013 at 11:21 AM, David Michael Barr <b@rr-dav.id.au> wrote:
>> On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell <pcampbell@kemitix.net> wrote:
>>> On Fri, Mar 1, 2013 at 2:28 AM, Kindjal <kindjal@gmail.com> wrote:
>>>> David Michael Barr <b <at> rr-dav.id.au> writes:
>>>>
>>>>> From a quick survey, it appears there are no more than 55 patches
>>>>> squashed into the submitted patch.
>>>>> As I have an interest in git-subtree for maintaining the out-of-tree
>>>>> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
>>>>> to make some sense of the organic growth that happened on GitHub.
>>>>> It doesn't appear that anyone else is willing to do this, so I doubt
>>>>> there will be any duplication of effort.
>>>>>
>>>>
>>>> What is the status of the work on git-subtree described in this thread?
>>>> It looks like it's stalled.
>>>>
>>>
>>> I hadn't been aware of that patch. Reading the thread David Michael
>>> Barr was going to try picking the patch apart into sensible chunks.
>>>
>>
>> Sorry for not updating the thread. I did end up moving onto other things.
>> I quickly realised the reason for globbing all the patches together was
>> that the individual patches were not well contained.
>> That is single patches with multiple unrelated changes and multiple
>> patches changing the same things in different directions.
>> To me this means that the first step is to curate the history.
>>
>>> If this work is still needing done I'd like to volunteer.
>>
>> You're most welcome. Sorry again for abandoning the thread.
>>
>> --
>> David Michael Barr
>
> Okay, I'll start picking the patch apart this week then feedback when
> I have a plan to tackle it all.
>
> --
> Paul [W] Campbell
>From a comparison of the tip for helmo's subtree-updates branch and
the current master these are the changes and features that the patch
is providing. I've listed the changes briefly per file, with a note
of the general action I plan to take. This is based on a simple diff,
so some changes are actually reversions to recent commits, which I
have tried to note.
Makefile
* Regresses two recent commits (8165be064e and d86848228f)
* ACTION: Ignore file
README.md
* Adds a markdown readme file (that github likes to have in root)
* Includes some install instructions in a pseudo man page format
* The INSTALL file covers all the information contained and is more up-to-date
* ACTION: Ignore file
git-subtree.sh
* OPTS_SPEC
* pull/push: options for repository and refspec are both optional,
[<repository> [<refspec>]]
* new sub-command: pull-all
* new sub-command: push-all
* new sub-command: list
* new sub-command: from-submodule
* new sub-command: prune
* new sub-command: diff
* new option for push: --force
* Trailing slash on prefix is removed
* Different pretty log format in cmd_commit getting piped to set some
environment variables
* Would revert: a5b8e28e4e
* Ignoring this change
* Removes all tests in cmd_add to check that refspec is valid
* I've posted a patch with new tests to the list recently that would
go in here
* Change reference to 'commit' into 'refspec' in error message in cmd_add
* Stores subtree metadata in .gittrees as:
[subtree "$dir"]
url = $repository
path = $dir
branch = $refspec
* Inadvertently commited a change to the linefeed character in
cmd_split for the activity indicator
* cmd_pull/cmd_push: reads options from .gitrees if not provided on
the command line
* Implementation of cmd_diff
* fetches remote repo as a temporary git-remote then uses
git-diff-tree to compare before removing the temporary git-remote
* Implementation of cmd_list as plain wrapper to new functions subtree_list
* Iterates over subtrees listed in .gittrees and prints out their details
* Dubious about greps used to get list from .gittrees
* Implementation of cmd_from-submodule
* Converts a git-submodule into a git-subtree
* Implementation of cmd_prune
* Removes entries from .gittrees where the $dir is missing
* Dubious about greps used to get list from .gittrees
* Implementation of cmd_pull-all
* Performs a git-subtree pull for each subtree
* Dubious about greps used to get list from .gittrees
* Implementation of cmd_push-all
* Perfroms a git-subtree push for each subtree
* Dubious about greps used to get list from .gittrees
git-subtree.txt
* Adds brief descriptions for commands:
* pull-all
* push-all
* list
* from-submodule
* prune
* diff ("TO BE DOCUMENTED")
* Notes optional -f|--force for push sub-command
* fixes a typo in text for Example 1 (s/incldued/included/)
t/t7900.sh
* Add numeric comments for each test
* recently removed (144797d720) in master so don't add them back
* ACTION: Ignore file
test.sh
* Legacy tests
* ACTION: Ignore file
My next step will be to find the commits (from helmo's
subtree-updates-merged branch) that provide the features above that I
want to keep and cherry-pick them into a new branch (or two).
--
Paul [W] Campbell
^ permalink raw reply
* [PATCH] match_push_refs(): nobody sets src->peer_ref anymore
From: Junio C Hamano @ 2013-03-04 22:36 UTC (permalink / raw)
To: git
In ancient times, we used to disallow the same source ref to be
pushed to more than one places, e.g. "git push there master:master
master:naster" was disallowed. We later lifted this restriction
with db27ee63929f (send-pack: allow the same source to be pushed
more than once., 2005-08-06) and there no longer is anybody that
sets peer_ref for the source side of the ref list in the push
codepath since then.
Remove one leftover no-op in a loop that iterates over the source
side of ref list (i.e. our local ref) to see if it can/should be
sent to a matching destination ref while skipping ones that is
marked with peer_ref (which will never exist, so we do not skip
anything).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
remote.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/remote.c b/remote.c
index e53a6eb..bac2b02 100644
--- a/remote.c
+++ b/remote.c
@@ -1227,9 +1227,6 @@ int match_push_refs(struct ref *src, struct ref **dst,
const struct refspec *pat = NULL;
char *dst_name;
- if (ref->peer_ref)
- continue;
-
dst_name = get_ref_match(rs, nr_refspec, ref, send_mirror, FROM_SRC, &pat);
if (!dst_name)
continue;
--
1.8.2-rc2-182-g857a7fa
^ permalink raw reply related
* Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From: Junio C Hamano @ 2013-03-04 23:00 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Eric Cousineau, git
In-Reply-To: <51351CF5.7010308@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Please don't attach your patches, see Documentation/SubmittingPatches on
> how to post patches to this list.
>
> Am 04.03.2013 09:41, schrieb Eric Cousineau:
>> In this patch, foreach --recursive acts depth-first, much like the default
>> behavior described in the patch by Imram Yousuf in this
>> post <http://marc.info/?l=git&m=121066084508631&w=2>.
>> Changes were made so that the submodule "Entering ..." message was right
>> next to the output generated by the command too.
>> It also adds the --parent option for executing the command in the
>> supermodule as well.
>
> From reading the linked pages I assume a valid use case you have is:
>
> git submodule foreach --recursive 'git add -A && git commit ...'
>
> This will currently not work because the depth first algorithm of foreach
> will execute the command /before/ recursing deeper. You'd need it to
> execute the command /after/ returning from the deeper level (which is what
> your patch seems to be about).
> ...
> What we currently get from your example is:
> Entering 'a'
> Entering 'a/b'
> Entering 'a/b/d'
> ...
> Entering 'c'
> Entering 'd'
> Me thinks this is what most users would expect of a recursion, enter each
> level before descending into the next.
>
> For your use case you'd need to have:
> Entering 'a/b/d'
> Entering 'a/b'
> Entering 'a/c'
> ...
> Entering 'c'
> Entering 'd'
> (Please note that this is still depth-first)
>
> I won't object to adding an option to foreach that will execute the command
> after recursing (but I'm not convinced --parent is a very good name for that).
Are you comparing pre-order vs post-order traversal?
Both can be useful depending on what you are trying to achieve. You
need a pre-order traversal (i.e. you "visit" and perform some action
on the node and then descend into its children) if you need to do
some preparation before you visit deeper levels; you need a
post-order traversal (i.e. you "visit" and perform some action on
the node after you have done all its children) if you know you will
be readly only after you are done with all your children.
You can throw in in-order traversal to the mix (i.e. you "visit" and
perform some action on the node after visiting some but not all of
your children and then continue visiting the remainder of your
children), but I do not know what practical value you would get out
of it.
So if you want a single boolean to toggle between the current
behaviour and the other one, it would be --post-order. But you may
at least want to consider pros and cons of allowing users to give
two separate commands, one for the pre-order visitation (which is
the current "command") and the other for the post-order
visitation. Being able to run both might turn out to be useful.
^ permalink raw reply
* rebase destroys branches
From: Gene Thomas [DATACOM] @ 2013-03-04 23:06 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
Hello,
I am evaluating git for use in a company. Please correct if I am wrong. I am concerned that an inexperienced developer could mistakenly rebase branches, destroying the original branch. Attached is a script (Windoze) that shows the 'topic' branch being moved!, after the rebase we are unable to see the original branch, read it's history or find it's commit points.
Surely no operation should remove anything from the repository. Operations like this irreversibly break the repository . When rebasing the original branch must be retained.
Yours faithfully,
Gene Thomas.
[-- Attachment #2: git-test.bat --]
[-- Type: application/octet-stream, Size: 1196 bytes --]
rem https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
rem (c) 2013 Gene Thomas
rem Datacom
rem Gene.Thomas@datacom.co.nz
if exist "git-test" rmdir /q /s git-test
mkdir git-test
cd git-test
git init
rem ==========================
echo d > d.txt
git add d.txt
git tag d
git commit -a -m d
echo e > e.txt
git add e.txt
git tag e
git commit -a -m e
git branch topic
git checkout topic
echo a > a.txt
git add a.txt
git tag a
git commit -m a
echo b > b.txt
git add b.txt
git tag b
git tag v2.0
git commit -a -m b
echo c > c.txt
git add c.txt
git tag c
git commit -a -m c
git log
rem ==========================
git checkout master
echo f > f.txt
git add f.txt
git tag f
git commit -a -m f
echo g > g.txt
git add g.txt
git tag g
git commit -a -m g
rem ==========================
git checkout topic
git rebase master
git log
rem ==========================
git checkout v2.0
git branch
rem we are on the "(no branch)" psuedo branch
rem origional 'topic' branch is lost
rem commits are still in the repositry
rem but can only be referenced by hash or tag
rem a mistake would destroy the history
^ 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