* Re: [BUG ?] completion of stash name with git stash
From: Thomas Rast @ 2012-01-19 16:18 UTC (permalink / raw)
To: Mathieu CLAVEL; +Cc: git
In-Reply-To: <loom.20120119T141601-606@post.gmane.org>
Mathieu CLAVEL <math.clavel@gmail.com> writes:
> I'm using mysgit 1.7.8 on XP.
>
> I think the stash name completion has a problem.
> I don't know if it's a problem from my system, mysgit or git.
>
> Here are the steps to reproduce (you need to have at least 2 stashed commits).
> '+ tab =>' means using the tab to autocomplete the current command. Left part is
> before completion, right tab is after completion.
>
> $ git stash list
> stash@{0}: WIP on feature/preservation_offres: 7f2c9a8 import.cmd : import par
> lot de 10.000 contrats
> stash@{1}: WIP on feature/echeancier: ddb7bb0 Mockito : 1.8.5 -> 1.9.0
>
> $ git stash drop '+ tab =>' $ git stash drop stash@{
>
> $ git stash drop stash@{0 '+ tab =>' $ git stash drop stashstash@{0}
>
> I don't know if it's relevant, but I also have 'git flow' and 'git flow
> completion' installed, and as said in a previous thread, 'git flow completion'
> isn't working with alias [2].
This works for me using git completion as shipped with v1.7.9-rc2 and
bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
stashes as expected. Which bash version are you using?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [BUG ?] completion of stash name with git stash
From: Mathieu CLAVEL @ 2012-01-19 16:34 UTC (permalink / raw)
To: git
In-Reply-To: <87lip3mzsz.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
> This works for me using git completion as shipped with v1.7.9-rc2 and
> bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
> stashes as expected. Which bash version are you using?
$ bash --version
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.
It's the version ship with the last version of msysGit.
I'm not sure I can update bash on Windows without any risk to break something.
So, do you think it's coming from the bash version ?
^ permalink raw reply
* Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 17:20 UTC (permalink / raw)
To: git
In-Reply-To: <CADo4Y9jGYJasDL9m7_50aOTrOyoezdyg=vcsZhQ87Qk-1XfTUQ@mail.gmail.com>
I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
The problem I'm running into is that whenever I change a file in a
directory, I have to bump up the version number in the configuration
file. The larger version value in the config file causes my changes
to be loaded over the old ones.
Most of my commits are edits to a file like "foo.js" and an increment
to the version number in "config". Ideally, each of my features
should live in a single commit and I should be able to make a sequence
of them, each time incrementing the version number in config.
The problem I'm running into starts with me editing version=100. I
create new commits where I set the version to 101, 102, 103, 104.
When I go to push ("git svn dcommit"), my coworkers have incremented
the version to 103. So, I rebase my changes, and get conflicts every
time because of the version number!
Is there a good way to avoid these conflicts? Is there a hook I can
write? Is there a change to this process that would work smoother
with Git and its distributed development? It's okay if the version
number skips numbers (e.g., jumps from 100 to 104), as long as it
increases.
Thanks,
Mike
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: demerphq @ 2012-01-19 18:12 UTC (permalink / raw)
To: mike; +Cc: git
In-Reply-To: <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
On 19 January 2012 18:20, Michael Nahas <mike.nahas@gmail.com> wrote:
> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.
Stop using version numbers and start using the git sha1 of the code
you are using.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [BUG ?] completion of stash name with git stash
From: Thomas Rast @ 2012-01-19 18:14 UTC (permalink / raw)
To: Mathieu CLAVEL; +Cc: git
In-Reply-To: <loom.20120119T172954-563@post.gmane.org>
Mathieu CLAVEL <math.clavel@gmail.com> writes:
> Thomas Rast <trast <at> student.ethz.ch> writes:
>
>> This works for me using git completion as shipped with v1.7.9-rc2 and
>> bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
>> stashes as expected. Which bash version are you using?
>
>
> $ bash --version
> GNU bash, version 3.1.0(1)-release (i686-pc-msys)
> Copyright (C) 2005 Free Software Foundation, Inc.
>
> It's the version ship with the last version of msysGit.
> I'm not sure I can update bash on Windows without any risk to break something.
> So, do you think it's coming from the bash version ?
Indeed, I compiled bash 3.1 and with that (and otherwise the same bashrc
etc.) I can reproduce. Ditto for 4.0-rc1, which was the newest version
in the repository where I found the bash source[1], so I couldn't
bisect. Perhaps if you can hunt down something newer you could try to
find the version where it starts working.
[1] git://gitorious.org/bash/bash.git
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-19 18:30 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, Alex Riesen,
Git Mailing List
In-Reply-To: <4F17C294.6010004@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> ... We have, e.g., NO_MMAP, and I can set it to request
> that some alternative is used, even if I have a working mmap(). The option
> name "NO_GETTEXT" is in exactly the same spirit.
>
>> In the current approach we take for shell scripts, we cannot have "No i18n
>> whatsoever and messages are emit with printf and echo". We always have to
>> go through gettext/eval_gettext even though they may be an implementation
>> that does not do i18n at all.
>
> Just like we go through _() in C code, even though there may be an
> implementation that does not do i18n at all, right?
Yes, just like that. The small detail that _() can be #define'd out to
empty while gettext/eval_gettext cannot be made to be no-impact like that
does not really matter.
> In C, it is easy, in shell code it may be more involved.
Correct.
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-19 18:46 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <8762g87y4q.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> [dropped Dieter as this really goes off on an internal tangent]
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> If somebody is writing a script using "git add" (which is not recommended
>> to begin with)
>
> Can we still stick to that stance? Our tests are increasingly using
> 'git add' instead of 'git update-index --add':
>
> $ git grep 'git[ -]add' t/ | wc -l
> 1540
> $ git grep 'git[ -]update-index --add' t/ | wc -l
> 269
> $ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l
> 251
> $ git grep 'git[ -]add' v1.6.0 t/ | wc -l
> 705
Stop being silly.
Have you actually looked at these usage? Some of them are genuinely
testing if "git add" works correctly, so it is out of the scope of this
discussion, but others that could be "git update-index" are feeding the
paths known to the script to exist (and we want 'git add' to error out
if that is not the case).
More generally, scripts in t/ directories are "scripts", but it is totally
different from the kind of "user facing script that behaves as if it is a
complete command, taking its own command line arguments, passing them
through to the underlying plumbing commands".
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 18:48 UTC (permalink / raw)
To: demerphq; +Cc: git
In-Reply-To: <CANgJU+WWq=+BP1ZDbGY3weB5Xey2TtbryDJvz5=eMLFzNet3xQ@mail.gmail.com>
On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
> Stop using version numbers and start using the git sha1 of the code
> you are using.
>
> Yves
1. Others in the group use SVN.
2. The version number needs to be increasing, to work with the current
process. SHA1's are random.
3. The "git sha1" for the commit/snapshot cannot be put into the
config file, which is part of the snapshot.
Mike
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Carlos Martín Nieto @ 2012-01-19 19:20 UTC (permalink / raw)
To: mike; +Cc: git
In-Reply-To: <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:
> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
Is this a deployment script that does this? Why can't it look at whether
files have changed? If a feature isn't ready for production, why is it
in a branch that gets deployed?
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
So if you've changed the file but don't increase the config file's
version, it means that the change isn't ready for production? If that's
the case, you've just implemented branches, poorly.
Contrary to what apparently many people think, subversion does support
branches. Get your team to use them.
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
This sounds like a race condition that the svn users might be avoiding
by committing everything immediately. Sounds like a buggy development
process.
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.
You could write a merge driver that detects this situation and writes in
a higher number, but it's all working around the fact that it's a race
condition.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] add a Makefile switch to avoid gettext translation in shell scripts
From: Alex Riesen @ 2012-01-19 19:52 UTC (permalink / raw)
To: Git Mailing List
Cc: Ævar Arnfjörð Bjarmason, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <CALxABCbaBmP6k5TYrYLCYm8oiv=9cF=N7_opSTKUnbkz5b-cwg@mail.gmail.com>
Some systems have gettext.sh (GNU gettext) installed, but it is either broken
or misconfigured in such a way so its output is not usable.
For instance, on this particular system, a Cygwin installations gettext
produces no output whatsoever.
In case the users of these systems are unable or not interested in fixing
them, setting the new Makefile switch should help:
USE_FALLTHROUGH_GETTEXT_SCHEME=yes
This will replace the translation routines with fallthrough versions, which
currently used only for regression testing.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Thu, Jan 19, 2012 10:13:20 +0100:
> On Thu, Jan 19, 2012 at 00:18, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > It makes sense to prefer the system functions by default in both
> > cases, but when the OS one can be broken or lacking we can just add
> > probes or Makefile options like we do for fnmatch() with the
> > NO_FNMATCH_CASEFOLD switch.
>
> Yes, and I personally shall welcome a chance to insult the local IT
> by suggesting BROKEN_SH_GETTEXT. Not that they get the point...
I believe this patch does just that. It is certainly enough for my purposes.
The copy-paste error noticed by Jonathan is also fixed, thanks!
I didn't add the tracking of the switch in GIT-BUILD-OPTIONS: didn't found
how to do it quickly enough in this time of evening, and gave up, thinking
that no one sane would need to set the option anyway. So at the moment a
"make clean" needed when changing it.
Makefile | 4 ++
git-sh-i18n.sh | 102 +++++++++++++++++++++++++++-----------------------------
2 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..806d126 100644
--- a/Makefile
+++ b/Makefile
@@ -47,6 +47,9 @@ all::
# A translated Git requires GNU libintl or another gettext implementation,
# plus libintl-perl at runtime.
#
+# Define USE_FALLTHROUGH_GETTEXT_SCHEME, if you don't want to trust the
+# installed gettext translation of the shell scripts output.
+#
# Define HAVE_LIBCHARSET_H if you haven't set NO_GETTEXT and you can't
# trust the langinfo.h's nl_langinfo(CODESET) function to return the
# current character set. GNU and Solaris have a nl_langinfo(CODESET),
@@ -1887,6 +1890,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's|@@LOCALEDIR@@|$(localedir_SQ)|g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@USE_FALLTHROUGH_GETTEXT_SCHEME@@/$(USE_FALLTHROUGH_GETTEXT_SCHEME)/g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+
endef
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..da8b214 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -16,61 +16,44 @@ else
fi
export TEXTDOMAINDIR
-if test -z "$GIT_GETTEXT_POISON"
+GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
+if test -n "@@USE_FALLTHROUGH_GETTEXT_SCHEME@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
+then
+ : no probing necessary
+elif test -n "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
- then
- # This is GNU libintl's gettext.sh, we don't need to do anything
- # else than setting up the environment and loading gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Try to use libintl's gettext.sh, or fall back to English if we
- # can't.
- . gettext.sh
-
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
- then
- # We don't have gettext.sh, but there's a gettext binary in our
- # path. This is probably Solaris or something like it which has a
- # gettext implementation that isn't GNU libintl.
- GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Solaris has a gettext(1) but no eval_gettext(1)
- eval_gettext () {
- gettext "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
-
- else
- # Since gettext.sh isn't available we'll have to define our own
- # dummy pass-through functions.
-
- # Tell our tests that we don't have the real gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- gettext () {
- printf "%s" "$1"
- }
-
- eval_gettext () {
- printf "%s" "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
- fi
-else
- # Emit garbage under GETTEXT_POISON=YesPlease. Unlike the C tests
- # this relies on an environment variable
-
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
+elif type gettext.sh >/dev/null 2>&1
+then
+ # This is GNU libintl's gettext.sh, we don't need to do anything
+ # else than setting up the environment and loading gettext.sh
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
+elif test "$(gettext -h 2>&1)" = "-h"
+then
+ # We don't have gettext.sh, but there's a gettext binary in our
+ # path. This is probably Solaris or something like it which has a
+ # gettext implementation that isn't GNU libintl.
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
+fi
+export GIT_INTERNAL_GETTEXT_SH_SCHEME
+case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
+gnu)
+ # Try to use libintl's gettext.sh, or fall back to English if we
+ # can't.
+ . gettext.sh
+ ;;
+solaris)
+ # Solaris has a gettext(1) but no eval_gettext(1)
+ eval_gettext () {
+ gettext "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+poison)
+ # Used in tests
gettext () {
printf "%s" "# GETTEXT POISON #"
}
@@ -78,7 +61,20 @@ else
eval_gettext () {
printf "%s" "# GETTEXT POISON #"
}
-fi
+ ;;
+*)
+ gettext () {
+ printf "%s" "$1"
+ }
+
+ eval_gettext () {
+ printf "%s" "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+esac
# Git-specific wrapper functions
gettextln () {
--
1.7.9.rc1.92.ga90a1
^ permalink raw reply related
* [RFC] Making pathspec limited log play nicer with --first-parent
From: Junio C Hamano @ 2012-01-19 19:58 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
I often find myself frustrated when I receive an update to a part of the
project and want to find the latest commit that merges the topic branch
that touched the same area.
For example, I wanted to find the latest merge of any git-p4 related topic
so that I can fork a new topic branch to keep Luke's updates posted today.
Without pathspec, "git log --first-parent" traverses the first-parent
chain just fine, and "-m --stat" shows the list of paths touched by the
merge, so we _could_ ask the question this way:
$ git log --first-parent --oneline -m --stat master |
sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail
The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates',
2012-01-06) was such a commit.
But a more natural way to spell it does not work as expected:
$ git log --first-parent --oneline -m --stat -1 master -- \
contrib/fast-import/git-p4
This finds ecb7cf9 (git-p4: rewrite view handling, 2012-01-02), which is a
part of the merged topic branch and is _not_ on the first-parent path from
the 'master':
$ git show-branch 8cbfc11 ecb7cf9
! [8cbfc11] Merge branch 'pw/p4-view-updates'
! [ecb7cf9] git-p4: rewrite view handling
--
- [8cbfc11] Merge branch 'pw/p4-view-updates'
+ [8cbfc11^2] git-p4: view spec documentation
++ [ecb7cf9] git-p4: rewrite view handling
The problem happens when the merge simplification logic kicks in when the
traversal inspects the merge 8cbfc11. In this case, the history leading to
the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic
forked from it, and the result of the merge is simply a copy from the tip
of the topic branch in the view limited by the given pathspec. The merge
simplification logic discards the first-parent of the merge and pretends
as if the sole parent of the merge is its second parent, i.e. the tip of
the topic. The history traversal veers off to the side branch, possibly
skipping a large swath of the mainline history if the topic forked from it
long in the past, but that only happens when the mainline did not touch
the paths in the limited view since the side topic forked, so it is not
losing information---but it still is wrong to show the commits on the side
topic when we are explicitly asked to show the first-parent chain.
Here is an attempt to fix this issue, by not allowing us to compare the
merge result with anything but the first parent when --first-parent is in
effect, to avoid the history traversal veering off to the side branch.
As this touches deep innards of a scary hairball that is the revision
traversal machinery, I am obviously not considering it as a 1.7.9
material, but I think we would want to fix it at some point, hopefully
soon.
With this patch, the "more natural way" finds the merge commit I am
looking for.
Comments?
---
revision.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 064e351..9e4596d 100644
--- a/revision.c
+++ b/revision.c
@@ -416,7 +416,7 @@ static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp, *parent;
- int tree_changed = 0, tree_same = 0;
+ int tree_changed = 0, tree_same = 0, nth_parent = 0;
/*
* If we don't do pruning, everything is interesting
@@ -444,6 +444,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
while ((parent = *pp) != NULL) {
struct commit *p = parent->item;
+ if (revs->first_parent_only && nth_parent++)
+ break;
if (parse_commit(p) < 0)
die("cannot simplify commit %s (because of %s)",
sha1_to_hex(commit->object.sha1),
^ permalink raw reply related
* Re: Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 20:02 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1327000803.5947.59.camel@centaur.lab.cmartin.tk>
I'm guessing here, but I believe the "version number" is used to make
a directory on the production machine. Thus, older versions of the
javascript are available on the production machines under their older
version number. If there's an issue in production with the new
version, code can be redirected to use the older version that is still
in its directory.
So it probably looks like:
/100/js/<files>
/101/js/<files>
/103/js/<files>
/104/js/<files>
If something goes wrong with version 104, the admin can just tell the
machine to use version 103 instead of 104.
You're right that incrementing this version number is probably not an
issue for SVN users because they put N features in a single commit and
they update the version number once. With git, a user can put N
features in N commits and changing the version number really belongs
in each commit. This makes rebasing suck.
On Thu, Jan 19, 2012 at 2:20 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:
>> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>>
>> The problem I'm running into is that whenever I change a file in a
>> directory, I have to bump up the version number in the configuration
>> file. The larger version value in the config file causes my changes
>> to be loaded over the old ones.
>
> Is this a deployment script that does this? Why can't it look at whether
> files have changed? If a feature isn't ready for production, why is it
> in a branch that gets deployed?
>
>>
>> Most of my commits are edits to a file like "foo.js" and an increment
>> to the version number in "config". Ideally, each of my features
>> should live in a single commit and I should be able to make a sequence
>> of them, each time incrementing the version number in config.
>>
>
> So if you've changed the file but don't increase the config file's
> version, it means that the change isn't ready for production? If that's
> the case, you've just implemented branches, poorly.
>
> Contrary to what apparently many people think, subversion does support
> branches. Get your team to use them.
>
>> The problem I'm running into starts with me editing version=100. I
>> create new commits where I set the version to 101, 102, 103, 104.
>> When I go to push ("git svn dcommit"), my coworkers have incremented
>> the version to 103. So, I rebase my changes, and get conflicts every
>> time because of the version number!
>
> This sounds like a race condition that the svn users might be avoiding
> by committing everything immediately. Sounds like a buggy development
> process.
>
>>
>> Is there a good way to avoid these conflicts? Is there a hook I can
>> write? Is there a change to this process that would work smoother
>> with Git and its distributed development? It's okay if the version
>> number skips numbers (e.g., jumps from 100 to 104), as long as it
>> increases.
>
> You could write a merge driver that detects this situation and writes in
> a higher number, but it's all working around the fact that it's a race
> condition.
>
> cmn
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: PJ Weisberg @ 2012-01-19 19:58 UTC (permalink / raw)
To: mike; +Cc: demerphq, git
In-Reply-To: <CADo4Y9is9mBOJaU+YRTMedTz7FfDrMFoDiqiUvQpVxQpyariPQ@mail.gmail.com>
On Thu, Jan 19, 2012 at 10:48 AM, Michael Nahas <mike.nahas@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
>> Stop using version numbers and start using the git sha1 of the code
>> you are using.
>>
>> Yves
>
> 1. Others in the group use SVN.
> 2. The version number needs to be increasing, to work with the current
> process. SHA1's are random.
> 3. The "git sha1" for the commit/snapshot cannot be put into the
> config file, which is part of the snapshot.
Suggestion #1: Just put $Rev$ into the file and be done with it until
the team moves over to Git (at which point you can figure something
else out).
Suggestion #2: In your release process, put something like `sed -e
"s/@@id@@/$(date +%s)/" source-dir/config > release-dir/config`
-PJ
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 20:06 UTC (permalink / raw)
To: PJ Weisberg; +Cc: demerphq, git
In-Reply-To: <CAJsNXTkDdHTMqmXCynT2nEYyuTmSF53RVtG2V+v7b+qcsYYufg@mail.gmail.com>
> Suggestion #1: Just put $Rev$ into the file and be done with it until
> the team moves over to Git (at which point you can figure something
> else out).
>
> Suggestion #2: In your release process, put something like `sed -e
> "s/@@id@@/$(date +%s)/" source-dir/config > release-dir/config`
>
> -PJ
Ideally, this value only increments with a change in a certain directory.
I think using either $Rev$ or a data+time value conditioned on a file
changing in a directory might work. Thanks!
Mike
^ permalink raw reply
* Re: [RFC] Making pathspec limited log play nicer with --first-parent
From: Linus Torvalds @ 2012-01-19 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uqvjwga.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Thu, Jan 19, 2012 at 11:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Comments?
Looks conceptually right, but I do have to admit to hating that new variable.
I don't see a better way to do it, though. Sure, you could do it with just
if (revs->first_parent_only && pp != &commit->parents)
break;
and avoid the new variable that way, but that replaces the annoying
variable with a pretty subtle thing.
Or we could re-write that while() loop and move the 'parent' variable
into it. Like the appended untested thing.
But maybe your patch is better, and my dislike for that parent counter
is just irrational.
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1606 bytes --]
revision.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/revision.c b/revision.c
index 064e35108478..5e8eb379c369 100644
--- a/revision.c
+++ b/revision.c
@@ -415,7 +415,7 @@ static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
{
- struct commit_list **pp, *parent;
+ struct commit_list **pp;
int tree_changed = 0, tree_same = 0;
/*
@@ -441,8 +441,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
return;
pp = &commit->parents;
- while ((parent = *pp) != NULL) {
- struct commit *p = parent->item;
+ do {
+ struct commit_list *parent = *pp;
+ struct commit *p;
+
+ if (!parent)
+ break;
+ pp = &parent->next;
+ p = parent->item;
if (parse_commit(p) < 0)
die("cannot simplify commit %s (because of %s)",
@@ -458,7 +464,6 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
* to lose the other branches of this
* merge, so we just keep going.
*/
- pp = &parent->next;
continue;
}
parent->next = NULL;
@@ -487,11 +492,10 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
case REV_TREE_OLD:
case REV_TREE_DIFFERENT:
tree_changed = 1;
- pp = &parent->next;
continue;
}
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
- }
+ } while (!revs->first_parent_only);
if (tree_changed && !tree_same)
return;
commit->object.flags |= TREESAME;
^ permalink raw reply related
* [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
From: Kirill Smelkov @ 2012-01-19 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kirill Smelkov
Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result
(from NEWS):
* WARNING: Backward-incompatibility!
Wildcards were not documented as returning sorted values, but the results
have been sorted up until this release.. If your makefiles require sorted
results from wildcard expansions, use the $(sort ...) function to request
it explicitly.
http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f
so we have to sort tests list or else they are executed in seemingly
random order even for -j1.
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
t/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index 9046ec9..66ceefe 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -17,9 +17,9 @@ DEFAULT_TEST_TARGET ?= test
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
-T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
-TSVN = $(wildcard t91[0-9][0-9]-*.sh)
-TGITWEB = $(wildcard t95[0-9][0-9]-*.sh)
+T = $(sort $(wildcard t[0-9][0-9][0-9][0-9]-*.sh))
+TSVN = $(sort $(wildcard t91[0-9][0-9]-*.sh))
+TGITWEB = $(sort $(wildcard t95[0-9][0-9]-*.sh))
all: $(DEFAULT_TEST_TARGET)
--
1.7.9.rc2.124.ge3180
^ permalink raw reply related
* Re: [RFC] Making pathspec limited log play nicer with --first-parent
From: Junio C Hamano @ 2012-01-19 20:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <CA+55aFxucaeX7it_Kj7WV3ZbwCukN+wvbuxqJzh3V5Rxz4ib1g@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Jan 19, 2012 at 11:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Comments?
>
> Looks conceptually right, but I do have to admit to hating that new variable.
>
> I don't see a better way to do it, though. Sure, you could do it with just
>
> if (revs->first_parent_only && pp != &commit->parents)
> break;
>
> and avoid the new variable that way, but that replaces the annoying
> variable with a pretty subtle thing.
>
> Or we could re-write that while() loop and move the 'parent' variable
> into it. Like the appended untested thing.
>
> But maybe your patch is better, and my dislike for that parent counter
> is just irrational.
I didn't like that parent counter that _only_ increments when we are
running under first-parent-only mode at the conceptual level. At the
implementation level, of course it is the right thing to do because
outside first-parent-only mode nobody cares about the parent counter,
so it is a valid but subtle optimization.
But I personally find your loop
do {
...
} while (!revs->first_parent_only);
is even more disgusting. It is misleading to have something that is not
supposed to change inside the loop as the terminating condition as if we
are saying "loop until somebody flips that bit" which is clearly not the
case.
So obviously I am saying that I do not think either patch is pretty
without offering a better alternative implementation, which is my usual
badness. As this is not an ultra urgent fix, I'll wait and see if somebody
else comes up with a more readable version.
Thanks for eyeballing the logic side of it, anyway. That was what I was
worried about the change the most.
^ permalink raw reply
* Re: [RFC] Making pathspec limited log play nicer with --first-parent
From: Linus Torvalds @ 2012-01-19 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwr8niftt.fsf@alter.siamese.dyndns.org>
On Thu, Jan 19, 2012 at 12:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> But I personally find your loop is even more disgusting
Yeah, I can't really argue with that.
The thing I was playing with was to move the entire loop content into
a helper function (which would return the new pp), and then the
"first-parent only" case just wouldn't do a loop at all.
But I couldn't be bothered. Your patch certainly does have the
advantage of being minimally intrusive.
Linus
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Jehan Bing @ 2012-01-19 21:07 UTC (permalink / raw)
To: git; +Cc: Michael Nahas
In-Reply-To: <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
On 2012-01-19 09:20, Michael Nahas wrote:
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.
Maybe you can do something with "git rerere"
(http://progit.org/2010/03/08/rerere.html). It supposed to automatically
resolve known conflicts.
I've never used myself, I just know it exists, so I don't know it's
usable in your case. But possibly you would pre-fill the rerere cache
(assuming that the format is simple enough) then just run rebase.
Jehan
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-19 21:26 UTC (permalink / raw)
To: Dieter Plaetinck; +Cc: Jens Lehmann, git
In-Reply-To: <20120119115216.2773a02f@plaetinck.be>
Dieter Plaetinck <dieter@plaetinck.be> writes:
> So basically, if this tool needs to check which files still/no-longer
> exist before calling git-add, that's vulnerable to race conditions.
I do not think you are solving the real problem in your script even if you
allowed "add --ignore-missing".
I suspect you are making things even worse by using "--ignore-missing" in
your script. If a user is actively updating the files in the filesystem,
at least "git add" without "--ignore-missing" would catch the case where
you _thought_ the user modified but still has the file, but in reality the
further updates in the working tree removed the file, which is a clear
indication that the rate you are processing the notify stream is slower
than the activity generated by the user and allows you to notice that you
may be better off waiting a bit until things calm down before running your
automated commit.
Also, with or without "--ignore-missing", I think we have safety valves to
cause "git add" fail if the file being added is updated while git is
working on it (i.e. we read and compute the object name, and then store it
compressed, and check the hash of what is stored matches the object name
we computed earlier, which would fail if the file is updated in the middle
at the right time).
This means that the "--ignore-missing" option will _not_ eliminate all
cases where "git add" may detect an error and fails. In other words, your
script needs to deal with error return from "git add" anyway even if we
applied your patch and you used "--ignore-missing" in your script.
I have to say that the basic premise of your script is simply broken, and
I am afraid that it is unfixable without an atomic snapshot support from
the underlying filesystem (i.e. take a snapshot, run 'git add' on it, and
then release the snapshot).
Having said all that, I do agree to the view that it is OK to let it
happen if the user explicitly asks a typo'ed pathspec on the command line
to be ignored for interactive use cases, and for that reason alone, I am
not fundamentally opposed to allowing the use of --ignore-missing outside
the --dry-run context.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] am: learn passing -b to mailinfo
From: Junio C Hamano @ 2012-01-19 21:26 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <a804650f805fd8c89a843302cb92bbbdf36b8c0b.1326710194.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> git-am could pass -k to mailinfo, but not -b. Introduce an option
> that does so. We change the meaning of the 'keep' state file, but are
> careful not to cause a problem unless you downgrade in the middle of
> an 'am' run.
>
> This uncovers a bug in mailinfo -b, hence the failing test.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> This fixes the broken 'if', and the use of 'echo' with an argument
> that starts with '-'.
After re-reading the code that parses the command line options given to
"am" and the previous invocation state we read from $dotest/*, however, I
think the way this change uses $keep makes things somewhat inconsistent
and harder to follow.
Currently the variables are given abstract meaning (e.g. "are we told to
record to utf8? yes or no") when we parse our command line options and
read from the previous invocation state, and then based on that abstract
meaning, a later code decides what exact option we throw at the git
commands we invoke (e.g. "utf8=t" -> "-u").
How about doing something like this instead at least for now? It might be
better to decide when we parse our options and $dotest/* immediately what
options we give to the git commands we run (which your patch does but only
to $keep option), but that kind of change (1) belongs to a separate topic
and should be done consistently to all options, and (2) I am not convinced
if it is necessarily a good change.
Thanks.
diff --git a/git-am.sh b/git-am.sh
index 6cdd591..8b755d9 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -15,6 +15,7 @@ q,quiet be quiet
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
+keep-non-patch pass -b flag to git-mailinfo
keep-cr pass --keep-cr flag to git-mailsplit for mbox format
no-keep-cr do not pass --keep-cr flag to git-mailsplit independent of am.keepcr
c,scissors strip everything before a scissors line
@@ -345,6 +346,8 @@ do
utf8= ;;
-k|--keep)
keep=t ;;
+ --keep-non-patch)
+ keep=b ;;
-c|--scissors)
scissors=t ;;
--no-scissors)
@@ -522,16 +525,25 @@ case "$resolved" in
fi
esac
+# Now, decide what command line options we will give to the git
+# commands we invoke, based on the result of parsing command line
+# options and previous invocation state stored in $dotest/ files.
+
if test "$(cat "$dotest/utf8")" = t
then
utf8=-u
else
utf8=-n
fi
-if test "$(cat "$dotest/keep")" = t
-then
- keep=-k
-fi
+keep=$(cat "$dotest/keep")
+case "$keep" in
+t)
+ keep=-k ;;
+b)
+ keep=-b ;;
+*)
+ keep= ;;
+esac
case "$(cat "$dotest/keepcr")" in
t)
keepcr=--keep-cr ;;
^ permalink raw reply related
* Re: Rebase and incrementing version numbers
From: Jon Seymour @ 2012-01-19 21:33 UTC (permalink / raw)
To: mike; +Cc: git
In-Reply-To: <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
On Fri, Jan 20, 2012 at 4:20 AM, Michael Nahas <mike.nahas@gmail.com> wrote:
> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.
>
> Thanks,
>
> Mike
I wonder if you can defer your changes to the config files until after
you have synced with the current SVN head, so that you typically only
modify the latest configuration file. Then use git to work out what
numbers you have to update (by working out which files you changed
that the SVN upstream has not seen yet). Not perfect, because of race
conditions, and may not work with your integration testing processes,
but perhaps worth considering.
Something like:
1. pull latest SVN
2. work on file
3. test. skip back to 2 until done.
4. ready to push to upstream
5. pull latest SVN
6. calculate configuration changes required
7. apply configuration changes
8. push work + configuration changes upstream
So, there is a window between steps 5 and 8 where you might still have
to deal with a conflict, but at least it should be much reduced.
I agree with other comments, though, a saner approach might be to
generate the configuration as part of a build process rather than
trying to maintain it in source control.
jon.
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-19 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vboq0ld5e.fsf@alter.siamese.dyndns.org>
On 1/18/2012 7:00 PM, Junio C Hamano wrote:
> Neal Kreitzinger<nkreitzinger@gmail.com> writes:
>
>>> Have you checked where in the filesystem hierarchy that script is run
>>> (hint: pwd)?
>>>
>> echo pwd in post-update echoes /path/WORKTREE/.git in git-push stdout.
>> ...
>> 'git-checkout -f' works manually, but in post-update hook...
>
> Stronger hint. Did you run "git checkout -f" in /path/WORKTREE/.git to
> back that "works manually" claim?
(Manual behavior):
If pwd is WORKTREE/ then git-checkout has correct effect, ie. worktree,
index, and HEAD match.
If pwd is WORKTREE/.git/ then git-checkout complains 'must be run in a
worktree' and has no effect.
(post-update hook behavior):
If pwd is WORKTREE/.git/ then git-push verbage does not complain, and
git-checkout exits zero status but has incorrect effect, ie. index and
HEAD match, but worktree matches HEAD@{1}.
If pwd is WORKTREE/ then git-push complains 'not a git repository', and
git-checkout exits non-zero status and has no effect, ie. worktree and
index match HEAD@{1}.
Evidence:
(post-update hook script):
MYPWD=`pwd`
echo $MYPWD
pushd /home/neal/FSNMSTHTML
MYPWD=`pwd`
echo $MYPWD
git checkout -f HEAD
if [ $? -ne 0 ]; then
echo "error on checkout!"
else
echo "checkout HEAD to non-bare remote current branch after push"
fi
echo $MYPWD
popd
MYPWD=`pwd`
echo $MYPWD
(git-push verbage):
$ git push origin HEAD
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 462 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
remote: warning: updating the current branch
remote: /home/neal/FSNMSTHTML/.git
remote: ~/FSNMSTHTML ~/FSNMSTHTML/.git
remote: /home/neal/FSNMSTHTML
remote: fatal: Not a git repository: '.'
remote: error on checkout!
remote: /home/neal/FSNMSTHTML
remote: ~/FSNMSTHTML/.git
remote: /home/neal/FSNMSTHTML/.git
To file:///home/neal/FSNMSTHTML
cee9269..34dc5a9 HEAD -> master
v/r,
neal
^ permalink raw reply
* Re: [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
From: Junio C Hamano @ 2012-01-19 22:01 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: git
In-Reply-To: <1327004244-18892-1-git-send-email-kirr@navytux.spb.ru>
Kirill Smelkov <kirr@navytux.spb.ru> writes:
> Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result
> (from NEWS):
>
> * WARNING: Backward-incompatibility!
> Wildcards were not documented as returning sorted values, but the results
> have been sorted up until this release.. If your makefiles require sorted
> results from wildcard expansions, use the $(sort ...) function to request
> it explicitly.
>
> http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f
>
> so we have to sort tests list or else they are executed in seemingly
> random order even for -j1.
I do not necessarily buy your "so we HAVE TO, OR ELSE".
Even though I can understand "We can sort the list of tests _if_ we do not
want them executed in seemingly random order when running 'make -j1'", I
tend to think that *if* is a big one. Aren't these tests designed not to
depend on each other anyway?
^ permalink raw reply
* Re: Unexpected "clean -Xd" behavior
From: pgit @ 2012-01-19 22:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jonathan Nieder, Pete Harlan, Git Mailing List, Shawn Bohrer
In-Reply-To: <CACsJy8AE+rwmOVUZez5GRXRHJsTy+W8ekzr59NTd7_C+gB0Byw@mail.gmail.com>
Thank you very much for looking at this.
2012/1/19 "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>:
> 2012/1/19 Jonathan Nieder <jrnieder@gmail.com>:
>> Pete Harlan wrote:
>>
>>> When a directory contains nothing but an ignored subdirectory, that
>>> subdirectory does not get removed by "git clean -Xdf".
>>>
>>> For example, in a new directory:
>>>
>>> # git init
>>> Initialized empty Git repository in /tmp/foo/.git/
>>> # echo a/ >.gitignore
>>> # git add .gitignore
>>> # git commit -m "Initial commit"
>>> [master (root-commit) c3af24c] Initial commit
>>> Â 1 files changed, 1 insertions(+), 0 deletions(-)
>>> Â create mode 100644 .gitignore
>>> # mkdir -p foo/a
>>> # touch foo/a/junk.o
>>> # git status
>>> # On branch master
>>> nothing to commit (working directory clean)
>>> # git clean -Xdn  # <--- DOES NOT MENTION foo/a
>
> -X is to remove ignored files _only_ (DIR_SHOW_IGNORED flag). And
> "foo" is not ignored according to .gitignore, so it cuts short there
> and never gets to "foo/a". -x works.
But the presence of a tracked file in foo makes it not cut short there, so
the logic seems a bit off. (If we're interested in removing ignored files
only, then the ignored files (not a tracked file) should trigger us
looking into foo. I don't know Git internals but I'm guessing it's not
quite that simple.)
> May be intentional, may be not
> (we hit a corner case). I don't know. Commit message b991625 might
> help:
>
> dir.c: Omit non-excluded directories with dir->show_ignored
>
> This makes "git-ls-files --others --directory --ignored" behave
> as documented and consequently also fixes "git-clean -d -X".
> Previously, git-clean would remove non-excluded directories
> even when using the -X option.
It can (and does) leave foo behind (because it's not ignored), but it
would conform better to the -X documentation if the ignored files were
removed.
BTW the above commit doesn't affect the behavior in this example.
If a fix isn't desirable then as Jonathan said updating the documentation
makes sense. (And those of us using it as a poor man's "make clean" can
just fix our Makefiles instead...)
Thanks,
--Pete
^ 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