* Re: log: option "--follow" not the default for a single file?
From: Jeff King @ 2011-12-01 20:36 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git
In-Reply-To: <CAN0XMOKrCovkmmdqu2GjsDof0wehfbf5a0EQuPo0q7GQaJ=GRQ@mail.gmail.com>
On Thu, Dec 01, 2011 at 09:28:31PM +0100, Ralf Thielow wrote:
> > It's possible, but it is changing the meaning of "git log foo". With
> > the current code, even if "foo" is currently a file, it will match
> > "foo/bar" in a prior revision. Switching this to "--follow" will not.
>
> Why does it actually match both things? I think that's
> maybe wrong.
Because that's what the path argument to "git log" is designed to do --
limit revision traversal based on pathspecs.
You can argue that the "--follow" semantics are more meaningful, but it
doesn't change the fact that it is a behavior change. We have to
consider not only backwards compatibility, but also the confusing-ness
of an inconsistent interface where:
git log foo bar
will treat "foo" as a pathspec, but:
git log foo
will treat it as a file.
> Also I can't use "git log" with another
> file/folder doesn't exists but in another revision. What actually
> exists is the file and that's imho the only thing that should match.
You can:
git log -- existed-long-ago
As a syntax shortcut, you can drop the "--". However, there is some
ambiguity with revision arguments, so git allows path arguments without
a "--" only when they exist in the filesystem (_not_ in a particular
revision).
-Peff
^ permalink raw reply
* Re: log: option "--follow" not the default for a single file?
From: Ralf Thielow @ 2011-12-01 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111201185230.GB2873@sigill.intra.peff.net>
> It's possible, but it is changing the meaning of "git log foo". With
> the current code, even if "foo" is currently a file, it will match
> "foo/bar" in a prior revision. Switching this to "--follow" will not.
Why does it actually match both things? I think that's
maybe wrong.
The folder was moved or delete so it doesn't exist in my
working directory. Also I can't use "git log" with another
file/folder doesn't exists but in another revision. What actually
exists is the file and that's imho the only thing that should match.
^ permalink raw reply
* Re: Copy branch into master
From: Neal Kreitzinger @ 2011-12-01 19:43 UTC (permalink / raw)
To: git; +Cc: 'Andrew Eikum', git
In-Reply-To: <CB09450076EA444CA289CDCB995F16A4@bny.us.bosch.com>
On 11/28/2011 1:30 PM, Ron Eggler wrote:
>> Sorry, I have no idea how to use any of the GUI tools. Perhaps your
>> GUI tool has a mailing list where you can ask about merge conflict
>> resolution?
>
> No problem, I actually got it all figured out now, and got my branch
> smoothly merged back into master.
>
That is not what you originally asked for. What you asked for was:
"Now I would like to copy exactly what I have in that branch back into
my master to have an exact copy in my master of what got deployed with
out any changes." If you did a git-merge then what you did was combine
master with DVT. That most likely did not make master equal to DVT. If
you run the following git-diff the results will likely show they do not
match:
$ git-diff --name-only sha1-of-master-after-DVT-merge
sha1-of-DVT-before-merge-to-master
If you merge branch A into branch B it does not make branch B equal to
branch A. It makes branch B a combination of branch B and branch A
(plus your merge conflict resolutions). If you truly want to make
master exactly match DVT then I recommend the following: (I'm assuming
this is not a superproject containing submodules, and that you are using
linux. I am using git 1.7.1.)
(Return master to the state it was in when you asked the question)
(1) git checkout master
(2) git branch BKUP-master-DVT-merge (backup your current post-merge
master to another branch)
(3) git reset --hard sha1-of-master-before-merge
(Return DVT to the state it was in when you asked the question)
(1) git checkout DVT
(2) git branch BKUP-DVT-B4-merge (backup current DVT if it has new work)
(3) git reset --hard sha1-of-DVT-before-merge
(Make master match DVT exactly)
(1) Use the "vendor branch code drop" method described in the git-rm
manpage* (see note on permissions below). (Use the git-archive command
to create your tarball of DVT for this.)
(2) After "vendor branch code drop" is committed, git-diff --name-status
master DVT (they should match, ie. no results that matter)
(3) git-tag the resulting commit to make it clear this is the version
you deployed.
*Note: if you are tracking permissions in git (executable vs.
non-executable bits) then you will need to accomodate and validate
permissions in your git-archive and/or ensure permissions are set
properly before committing your vendor branch code drop. Otherwise, you
will have permissions changes that do not exactly match DVT.
I recommend trying the above on a test copy of your repo to verify the
results are really what you want.
(tar up your repo as root to retain permissions, and untar in test dir)
(repo path = /home/me/MY-REPO)
(1) pwd ( = /home/me)
(2) mkdir test
(3) su root
(4) pwd ( = /home/me)
(5) tar -cvzf MY-REPO.tar.gz MY-REPO/
(6) cd test
(7) mv ../MY-REPO.tar.gz .
(8) tar -xvzf MY-REPO.tar.gz
(test repo path = /home/me/test/MY-REPO)
(9) exit
(10) cd /home/me/test/MY-REPO
(11) try out what I said on test/MY-REPO and then decide if you want to
do it on the real me/MY-REPO.
If you already have additional commits on master after your master-DVT
merge then they are backed up in the BKUP-master-DVT-merge branch you
made earlier. These commits can then be interactively rebased on your
remediated master. (Be aware of any possible unique master-DVT merged
code the new commits are dependent on. If so, that code needs to be
reincorporated instead of being unwittingly lost.)
All the above assumes that others have not already pulled your
master-DVT merge and based their work on it. If they have already
pulled your new master and based work on it then it may be too late for
this to be practical, or additional steps would be needed for others to
properly remediate. I'm assuming you have a known set of developers
pulling from you. It is possible for them to interactively rebase their
new work onto your remediated master and take the merged-master out of
their history. (Be aware of any possible unique master-DVT merged code
the new commits are dependent on. If so, that code needs to be
reincorporated instead of being unwittingly lost.)
Hope this helps.
v/r,
neal
^ permalink raw reply
* Re: Status after 'git clone --no-checkout' ?
From: Jeff King @ 2011-12-01 19:00 UTC (permalink / raw)
To: norbert.nemec; +Cc: git
In-Reply-To: <jb59h0$p3e$1@dough.gmane.org>
On Wed, Nov 30, 2011 at 02:02:22PM +0100, norbert.nemec wrote:
> what exactly is the status after 'git clone --no-checkout'? Is there
> any straightforward way how one could end up in this state starting
> from a regularly checked out repository?
You have a HEAD which points to some actual commit, but no index or
working tree. I don't think there is a particular name for this state.
You can get something similar in an existing repo by deleting all of the
working tree files and removing .git/index.
> 'git checkout' without any further options serves to move from the
> aforementioned special state to a regular checked out state.
> Otherwise it never seems to do anything. Are there any other
> situations where 'git checkout' on its own would have any effect?
By itself, I don't think so. But you can use "git checkout -f" to
discard changes in the index and working tree, setting them back to the
state in HEAD.
At one point, some people used "git checkout" as a no-op, because it
would print the "ahead/behind" information with respect to the upstream.
These days, that information is part of "git status", so I suspect
people use that instead.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC 1/2] pull: pass the --no-ff-only flag through to merge, not fetch
From: Samuel Bronson @ 2011-12-01 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcq0np35.fsf@alter.siamese.dyndns.org>
On Thu, Dec 1, 2011 at 1:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Samuel Bronson <naesten@gmail.com> writes:
>
>> Hmm, yes, I had noticed that it was a tristate (merge.ff clearly is),
>> and I guess --no-ff-only is a pretty ugly flag. I do have to ask,
>> though: why give --ff these new values? Wouldn't it make more sense to
>> reuse the values accepted by merge.ff; namely, 'true' (the implied
>> default), 'false', and 'only'?
>
> The 'true' and 'false' values to merge.ff are carry-over from the days
> when it was a boolean, _not_ a tristate. If we were to make the UI more
> rational by making it clear that this is not a boolean, it is a good time
> for us to aim a bit higher than merely repeating the mistakes we made in
> the past due to historical accident. In other words, we could add a
> synonym for the "default" mode in addition to "--ff=true" (and for the
> "always merge" mode in addition to "--ff=false") that makes it clear that
> the value is _not_ a boolean [*1*]. If we were to go the "--ff=<value>"
> route, we have to add support for other ways to spell boolean 'true'
> (e.g. 'yes', '1', and 'on') anyway, so it is not that much extra work to
> do so, I would think.
Sure, that makes sense. I was just a little worried that you might be
(accidentally) proposing that --ff use a different set of names than
merge.ff for a moment there...
>> Otherwise, this looks like a very nice way to implement what I want: I
>> guess it is probably a mistake that the existing (documented) flags do
>> not behave in this way?
>
> Yeah, right now if you say "merge --ff-only --no-ff", we say these are
> mutually exclusive (which is true), but if you think about the tristate
> nature of the 'ff' option and spell it differently in your head, i.e.
> "merge --ff=only --ff=never", it is reasonable to argue that we should
> apply the usual "last one overrides" rule and behave as if "merge --no-ff"
> were given (for the purpose of "last one overrides", the configured
> defaults can be treated as if they come very early on the command line).
> After all "merge --no-ff --ff" does seem to use the "last one overrides"
> rule.
Yes, I totally agree that it would make more sense that way; I
certainly tried that before I even began to look at any of the code.
> [Footnote]
>
> *1* Perhaps 'allowed' instead of 'normal' (which I wrote out of thin-air;
> I do not have any strong preference on the actual values) may be a better
> choice for such a "this is not a boolean" spelling for the default mode.
^ permalink raw reply
* Re: Workflow Recommendation - Probably your 1000th
From: Stephen Bash @ 2011-12-01 18:55 UTC (permalink / raw)
To: bradford; +Cc: git
In-Reply-To: <CAEbKVFSXn3we7Btb3fN5DUW7BMub_ZrBeUwLUZrRFTmESoW97A@mail.gmail.com>
----- Original Message -----
> From: "bradford" <fingermark@gmail.com>
> To: git@vger.kernel.org
> Sent: Thursday, December 1, 2011 1:26:10 PM
> Subject: Workflow Recommendation - Probably your 1000th
>
> You guys probably receive a ton of workflow related questions. I'm
> trying to convert from svn to git. In order to complete, I would
> like to be able to provide a workflow to our team. We typically go
> from dev -> qa -> production (Java and Rails projects). The problem
> is that sometimes QA can get backed up and we'll need to release
> something to production while QA is doing their thing. What is a
> good workflow? I would like to not use git-flow, because it's another
> tool.
Hey wow... I read that Driessen's workflow post [1] a long time ago, but hadn't run into the git-flow tools until a few days ago. Guess I was just oblivious... Anyway, if it's any consolation, my company runs a model very much inspired by Driessen's post without using git-flow itself.
[1] http://nvie.com/posts/a-successful-git-branching-model/
> I've read suggestions to use environment branches (master,
> staging, production). I've also read not to do this and just use
> master, tagging your production releases. How well would our setup,
> where things can get backed up, work with the latter? Are there any
> alternative suggestions?
In our workflow we flip Driessen's model on its head. master is the newest code, while we branch off maintenance branches just before each release. We tag each release so it's easy to identify which versions in the field contain a given bug or fix (multiple minor versions come off a single maintenance branch). Our QA guys follow the maintenance branches (they're relatively stable). We recently had to do a hot-fix release which I think would be similar to your "release to production". Basically we found the last commit on the maintenance branch that was well tested, created a new branch from there, did the hot fix, QA did some real fast testing (sounds like you'd skip this step), and we shipped that. As always that hot-fix release gets tagged, so in the future we can still reference t
hat particular build (and in this case the branch merged back into the maintenance branch -- we've had other situations where the branch was simply deleted after tagging).
In the grand scheme of things our model isn't that different than Driessen's; we just name the branches differently. Commits go on the oldest branch that's safe for them, and then everything merges to the newer branches. Tags provide easy reference for where on a given branch a release came from.
Hope that helps.
Stephen
^ permalink raw reply
* Re: log: option "--follow" not the default for a single file?
From: Jeff King @ 2011-12-01 18:52 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git
In-Reply-To: <CAN0XMOJGm1frOi7FEke7LfHCSBt2DRn_npkdKe0m3qZ=hQPNHw@mail.gmail.com>
On Wed, Nov 30, 2011 at 07:38:23PM +0100, Ralf Thielow wrote:
> > pathspec. That may happen to match a single file in the current
> > revision, but to git it is actually a prefix-limiting pattern, and
> Is it possible to detect the case of a single file in the current
> revisionand use "--follow" by default for exactly that?
It's possible, but it is changing the meaning of "git log foo". With
the current code, even if "foo" is currently a file, it will match
"foo/bar" in a prior revision. Switching this to "--follow" will not.
-Peff
^ permalink raw reply
* Re: git merge strange result
From: Jeff King @ 2011-12-01 18:50 UTC (permalink / raw)
To: Catalin(ux) M. BOIE; +Cc: git
In-Reply-To: <alpine.LFD.2.02.1112011733070.32682@mail.embedromix.ro>
On Thu, Dec 01, 2011 at 05:36:00PM +0200, Catalin(ux) M. BOIE wrote:
> Below is a script that reproduce what a coleague of mine found.
> Seems that if in a branch we have a commit that is cherry-picked be
> master, than revert that commit in branch and merge branch in master,
> the revert is ignored. Is it normal?
Yes, it's by design. When doing a merge, we look at three points: the
tip of the current branch, the tip of the branch to be merged, and the
point at which history diverged (the "merge base"). We don't look
individually at the commits that happened between the merge base and
each tip.
The non-conflicting case for a 3-way merge is that one side makes some
change, but the other side does nothing. In this case, we include the
change in the merge result. But remember that we are only looking at
endpoints. So what the actual merge code sees is that one side's version
of a file is identical to the merge base's version, and that the other
side's version is now different.
In your case, one side makes the change, but then restores the original
state. So from the perspective of the merge code, no change happened at
all on that side.
-Peff
^ permalink raw reply
* Workflow Recommendation - Probably your 1000th
From: bradford @ 2011-12-01 18:26 UTC (permalink / raw)
To: git
You guys probably receive a ton of workflow related questions. I'm
trying to convert from svn to git. In order to complete, I would like
to be able to provide a workflow to our team. We typically go from
dev -> qa -> production (Java and Rails projects). The problem is
that sometimes QA can get backed up and we'll need to release
something to production while QA is doing their thing. What is a good
workflow? I would like to not use git-flow, because it's another
tool. I've read suggestions to use environment branches (master,
staging, production). I've also read not to do this and just use
master, tagging your production releases. How well would our setup,
where things can get backed up, work with the latter? Are there any
alternative suggestions?
Thanks,
Bradford
^ permalink raw reply
* Re: [PATCH] compat/getpass.c: Fix a sparse "symbol not declared" warning
From: Jeff King @ 2011-12-01 18:19 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <4ED69803.6070508@ramsay1.demon.co.uk>
On Wed, Nov 30, 2011 at 08:54:27PM +0000, Ramsay Jones wrote:
> When you next re-roll your most recent credentials/getpass series, could
> you please squash this patch in. (This patch was against pu @ 1cc922af,
> but I guess you need to apply a similar patch to commit 8eca119c "stub out
> getpass_echo function", 27-11-2011 instead)
Sure, makes sense. Thanks.
-Peff
^ permalink raw reply
* [PATCH] compat/getpass.c: Fix a sparse "symbol not declared" warning
From: Ramsay Jones @ 2011-11-30 20:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, GIT Mailing-list
In particular, sparse complains as follows:
SP compat/getpass.c
compat/getpass.c:5:6: warning: symbol 'getpass_echo' was not \
declared. Should it be static?
In order to suppress the warning, we include the getpass.h header
file which contains an appropriate extern declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Jeff,
When you next re-roll your most recent credentials/getpass series, could
you please squash this patch in. (This patch was against pu @ 1cc922af,
but I guess you need to apply a similar patch to commit 8eca119c "stub out
getpass_echo function", 27-11-2011 instead)
Thanks!
ATB,
Ramsay Jones
compat/getpass.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/compat/getpass.c b/compat/getpass.c
index b5bd1dd..a145d27 100644
--- a/compat/getpass.c
+++ b/compat/getpass.c
@@ -1,4 +1,5 @@
#include "../git-compat-util.h"
+#include "getpass.h"
#ifdef HAVE_DEV_TTY
--
1.7.7
^ permalink raw reply related
* [PATCH] Makefile: Add missing "sparse object" to gettext target-specific rule
From: Ramsay Jones @ 2011-11-30 20:43 UTC (permalink / raw)
To: avarab; +Cc: Junio C Hamano, GIT Mailing-list
In particular, we add gettext.sp to the target-specific rule which
adds the GIT_LOCALE_PATH setting to EXTRA_CPPFLAGS, otherwise sparse
complains thus:
SP gettext.c
gettext.c:125:25: error: undefined identifier 'GIT_LOCALE_PATH'
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Avar,
If you are going to re-roll your latest i18n patch (commit 6c856c48,
"i18n: add infrastructure for translating Git with gettext", 18-11-2011),
could you please squash this patch into it.
Thanks!
ATB,
Ramsay Jones
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index ac8c76d..f926b5f 100644
--- a/Makefile
+++ b/Makefile
@@ -2129,7 +2129,7 @@ config.sp config.s config.o: EXTRA_CPPFLAGS = \
attr.sp attr.s attr.o: EXTRA_CPPFLAGS = \
-DETC_GITATTRIBUTES='"$(ETC_GITATTRIBUTES_SQ)"'
-gettext.s gettext.o: EXTRA_CPPFLAGS = \
+gettext.sp gettext.s gettext.o: EXTRA_CPPFLAGS = \
-DGIT_LOCALE_PATH='"$(localedir_SQ)"'
http.sp http.s http.o: EXTRA_CPPFLAGS = \
--
1.7.7
^ permalink raw reply related
* Re: [PATCH/RFC 1/2] pull: pass the --no-ff-only flag through to merge, not fetch
From: Junio C Hamano @ 2011-12-01 18:06 UTC (permalink / raw)
To: Samuel Bronson; +Cc: git
In-Reply-To: <CAJYzjmep7sKxiSNhMzAX2DRYJhANDQkPL5pX4HOZ9CssJxcWbw@mail.gmail.com>
Samuel Bronson <naesten@gmail.com> writes:
> Hmm, yes, I had noticed that it was a tristate (merge.ff clearly is),
> and I guess --no-ff-only is a pretty ugly flag. I do have to ask,
> though: why give --ff these new values? Wouldn't it make more sense to
> reuse the values accepted by merge.ff; namely, 'true' (the implied
> default), 'false', and 'only'?
The 'true' and 'false' values to merge.ff are carry-over from the days
when it was a boolean, _not_ a tristate. If we were to make the UI more
rational by making it clear that this is not a boolean, it is a good time
for us to aim a bit higher than merely repeating the mistakes we made in
the past due to historical accident. In other words, we could add a
synonym for the "default" mode in addition to "--ff=true" (and for the
"always merge" mode in addition to "--ff=false") that makes it clear that
the value is _not_ a boolean [*1*]. If we were to go the "--ff=<value>"
route, we have to add support for other ways to spell boolean 'true'
(e.g. 'yes', '1', and 'on') anyway, so it is not that much extra work to
do so, I would think.
> Otherwise, this looks like a very nice way to implement what I want: I
> guess it is probably a mistake that the existing (documented) flags do
> not behave in this way?
Yeah, right now if you say "merge --ff-only --no-ff", we say these are
mutually exclusive (which is true), but if you think about the tristate
nature of the 'ff' option and spell it differently in your head, i.e.
"merge --ff=only --ff=never", it is reasonable to argue that we should
apply the usual "last one overrides" rule and behave as if "merge --no-ff"
were given (for the purpose of "last one overrides", the configured
defaults can be treated as if they come very early on the command line).
After all "merge --no-ff --ff" does seem to use the "last one overrides"
rule.
[Footnote]
*1* Perhaps 'allowed' instead of 'normal' (which I wrote out of thin-air;
I do not have any strong preference on the actual values) may be a better
choice for such a "this is not a boolean" spelling for the default mode.
^ permalink raw reply
* Re: [PATCH/RFC 1/2] pull: pass the --no-ff-only flag through to merge, not fetch
From: Samuel Bronson @ 2011-12-01 17:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vborsq45x.fsf@alter.siamese.dyndns.org>
On Wed, Nov 30, 2011 at 11:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Samuel Bronson <naesten@gmail.com> writes:
>
>> Without this, pull becomes unusable for merging branches when the config
>> option `merge.ff` is set to `only`.
>>
>> Signed-off-by: Samuel Bronson <naesten@gmail.com>
>
> I wonder why you need this. We have "git config --unset merge.ff" after
> all. From purely mechanstic point of view, being able to temporarily
> defeat a configuration variable makes perfect sense, but from the point of
> view of workflow, I am not sure if it is a good thing to even allow it in
> the first place in this particular case.
>
> Setting merge.ff to 'only' means you are following along other people's
> work and making nothing new on your own in this particular repository, no?
> Hence you won't be asking the upstream to pull from this repository, which
> in turn means that even if you made a merge by temporarily defeating the
> configuration setting with this patch, your future pulls will no longer
> fast forward, until somehow the upstream gets hold of your merge commit.
Actually, I wanted to set merge.ff to only avoid *accidentally*
merging origin/master onto my local master, when I would likely to
prefer to either rebase my work onto it, or retroactively put my work
in a branch and merge that *into* the real master branch; I would then
override only when I explicitly did want a merge.
(I actually have commit access to the repository in question, but wish
to avoid making others' commits to master look as if they were on side
branches.)
> By the way (this is a digression), I also have to say --no-ff-only is too
> *ugly* as a UI element, even though I know "git merge" already allows it
> by accident.
>
> "ff" is a tristate. By default, fast-forward is done when appropriate, and
> people can _refuse_ to fast-forward and force Git to create an extra merge
> commit. Or if you are strictly following along, you can say you _require_
> fast-forward and reject anything else. So it may make the UI saner if we
> updated the UI to allow users to say:
>
> --ff=normal the default
> --ff=never same as --no-ff that forces an extra merge commit
> --ff=required same as --ff-only
>
> while keeping the current --ff-only and --no-ff as backward compatibility
> wart.
Hmm, yes, I had noticed that it was a tristate (merge.ff clearly is),
and I guess --no-ff-only is a pretty ugly flag. I do have to ask,
though: why give --ff these new values? Wouldn't it make more sense to
reuse the values accepted by merge.ff; namely, 'true' (the implied
default), 'false', and 'only'?
Otherwise, this looks like a very nice way to implement what I want: I
guess it is probably a mistake that the existing (documented) flags do
not behave in this way?
^ permalink raw reply
* git merge strange result
From: Catalin(ux) M. BOIE @ 2011-12-01 15:36 UTC (permalink / raw)
To: git
Hello!
Below is a script that reproduce what a coleague of mine found.
Seems that if in a branch we have a commit that is cherry-picked be
master, than revert that commit in branch and merge branch in master, the
revert is ignored. Is it normal?
Thank you very much!
#!/bin/bash
set -e
rm -rf buba1
mkdir buba1
cd buba1
git init
echo -e "aaa\nbbb\nccc" > file1
git add file1
git commit -m "c1"
echo "Create branch b1..."
git branch b1
echo
echo "Create a bad fix..."
sed --in-place -e 's/bbb/bad line/' file1
git add file1
git commit -m "bad commit"
cat file1
echo
echo "Cherry pick on b1..."
git checkout b1
git cherry-pick -x master
echo
echo "Reverting on b1"
git revert --no-edit b1
echo
echo "Switch to master"
git checkout master
echo
echo "merge-base is `git merge-base --all master b1 | git name-rev --stdin`"
echo
echo "diff between master and b1..."
git diff master b1
echo
echo "Merge b1 in master"
git merge --verbose --log b1
if [ "`grep bad file1`" = "" ]; then
echo "good!"
else
echo "bad!"
fi
# it should prind "good"
--
Catalin(ux) M. BOIE
http://kernel.embedromix.ro/
^ permalink raw reply
* Re: mini-wierdness with "git am"
From: Andrew Wong @ 2011-12-01 15:38 UTC (permalink / raw)
To: Aghiles; +Cc: git list
In-Reply-To: <CAKCZoVb5-JfzTXK9pUoem_0oQHrSLkrxQZUOZGTX3GGgebPGwA@mail.gmail.com>
On 11/30/2011 06:12 PM, Aghiles wrote:
> At this point, my repository is back to ORIG_HEAD!
> Meaning that it reverted my preivous "git reset --hard HEAD~1".
>
This behavior seems to have been fixed in v1.7.3.5 and later. The new
behavior will skip the reverting, and only perform the clean up.
http://article.gmane.org/gmane.comp.version-control.git/164045
^ permalink raw reply
* Re: Anyone have a commit hook for forbidding old branches from being merged in?
From: Thomas Rast @ 2011-12-01 15:50 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
In-Reply-To: <CACBZZX4LyTaz=fU1vvgpeL904QFjJULCMVSP0uutcuxZT+-vWQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
>
> So before I write a hook to do this, is there anything that implements
> a hook that:
>
> * Checks if you're pushing a merge commit
> * If so, is that merge based off and old version of $MAINBRANCH
I think it suffices to check whether any boundary commit in the
updated range is older than what you allow, e.g.
while read old new rev; do
# omitted: check it's an update, i.e., neither old nor new is 0..0
git rev-list --boundary $old..$new |
sed -n 's/^-//p' |
xargs git rev-list --no-walk --before='cutoff limit' >bad
test -s bad || exit 1
done
(Not tested much; in particular I'm not sure you can get away without
limiting the number of args to rev-list to 1. A simple test seems to
indicate so, however.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2 5/5] bulk-checkin: replace fast-import based implementation
From: Junio C Hamano @ 2011-12-01 15:46 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8D5BqqkXCa7kczcNBxjt=G2d2ZXUToncR2pBGRuZ3gPKg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Thu, Dec 1, 2011 at 7:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -458,11 +459,15 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>> free(seen);
>> }
>>
>> + plug_bulk_checkin();
>> +
>> exit_status |= add_files_to_cache(prefix, pathspec, flags);
>>
>> if (add_new_files)
>> exit_status |= add_files(&dir, flags);
>>
>> + unplug_bulk_checkin();
>> +
>> finish:
>> if (active_cache_changed) {
>> if (write_cache(newfd, active_cache, active_nr) ||
>
> Also do the same for git-commit, except as-is commit case, for
> updating large files?
>
> update-index should also learn about this,...
I didn't do any of the above in this series and that was on purpose.
Getting plug/unplug (and all the machinery that they are related to) to do
the right thing when they are called is far more important at this stage
than figuring out when it is appropriate to plug and unplug in various
random programs, it is sufficient to have one canonical and simplest
callsite pair as an example in the primary interface to add new objects
(i.e. "git add") for that purpose, and it is not too cumbersome for early
adopters to remember using "git add" when adding oddball large blobs
instead of using "commit -a".
In short, I wanted to keep the patch to the minimum to avoid distracting
capable reviewers (which is in short supply these days).
I wouldn't stop you or anybody from preparing a patch series that adds
plug/unplug pairs before the machinery is perfected, so that such an
effort can expose a corner case where the machinery and the API presented
in this series is inadequate and can use improvements. Once the machinery
gets perfected, submit such a patch series to add users that are well
tested.
Thanks.
^ permalink raw reply
* Anyone have a commit hook for forbidding old branches from being merged in?
From: Ævar Arnfjörð Bjarmason @ 2011-12-01 15:34 UTC (permalink / raw)
To: Git Mailing List
I work on a web application that due to underlying database schema
changes etc only even compiles and runs for a given 2 week moving
window.
Thus if someone started a branch say 1 month ago, works on it one and
off, and then merges it back into the mainline it becomes impossible
to bisect that code if it has a problem. You either have to:
* Revert the whole merge
* Manually eyeball the code to see where the error might be
* Brute-force manually bisect it by checking out only the files
altered in those commits instead of the commit at a given
data. Usually individual files are still compatible with the new
code.
But the whole reason this is a problem is because people don't rebase
their branches before merging them in, unintentionally causing
problems.
So before I write a hook to do this, is there anything that implements
a hook that:
* Checks if you're pushing a merge commit
* If so, is that merge based off and old version of $MAINBRANCH
* Is the base of that branch more than N days old?
* If so reject the push
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: Carlos Martín Nieto @ 2011-12-01 14:30 UTC (permalink / raw)
To: John Twilley; +Cc: git
In-Reply-To: <CAEUMa-fhqS-dJUePznZrEsKVSMDiAs=-JX93XTXZEm71Oix-1Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8595 bytes --]
On Wed, Nov 30, 2011 at 11:13:20AM -0800, John Twilley wrote:
> On Wed, Nov 30, 2011 at 10:22, Carlos Martín Nieto <cmn@elego.de> wrote:
> > On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:
> >> Today someone asked me if there was a way to run git against a
> >> directory other than the current directory. I looked at the output of
> >> --help and ran this:
> >>
> >> $ git --work-tree blah status
> >>
> >> I got the following output:
> >>
> >> fatal: Not a git repository (or any parent up to mount parent /home)
> >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> >>
> >> I mistakenly thought the error message meant that blah was not a git
> >> repository. What it meant was that there was no .git in the current
> >> directory or any parent directory up to /home.
> >
> > Yes, git looks at the current directory and .git/ to see if there's a
> > git repository there. This is what happens unless you tell git to look
> > for it somewhere else.
>
> This makes perfect sense, because nearly every time I run git
> commands, I am somewhere within the working tree. The point of my
> post was that I was using --work-tree to tell git to look for the git
> repository somewhere else (the root of the specified working tree)
> which is not what git expected.
And as Junio said, git devs have never considered the case where you
want to run git from a directory, but have git look for the worktree +
repo in a different place. Since what you want to do is solved
trivially by cd'ing in a subshell "(cd blah && git status)" it's not
surprising that this hasn't come up.
>
> >> This command worked as expected:
> >>
> >> $ git --work-tree blah --git-dir blah/.git status
> >>
> >> The documentation is somewhat fuzzy about what constitutes a git
> >> repository. The gittutorial describes the git repository as .git when
> >> talking about "git init" while the Git User's Manual describes the git
> >> repository as the working tree and the special top-level directory
> >> named .git when talking about "git clone".
> >
> > A git repository is what's under .git/ (or in foo.git/ for bare
> > repos). Non-bare repositories have a working tree associated with
> > them, which by default lives just above the repository, because it'd
> > be silly to have it somewhere else by default. Often you can think of
> > both as the repository, as they're both. When you tell git to look for
> > the worktree somewhere else, you're only overriding that particular
> > variable, as git expects to be run from the repository (or just above,
> > in the worktree).
>
> And it's exactly this issue -- that sometimes the repository is just
> the git directory, and sometimes the repository is the working tree
> which contains the git directory at its root -- that caused the
> confusion and unexpected behavior. If I were to use a bare repository
> directly (something I've never done), I guess I might use --git-dir
> since the repository may not be named .git but instead something like
> proj.git. When I accessed a repository from outside its working tree,
> I expected --work-tree to cover the whole shebang. Obviously this
> discussion is exposing my relatively limited experience with git, but
> these assumptions do not seem unreasonable on their face.
You hardly ever need to use git directly on a bare repo, but when you
do, you can just it from inside the repo, but most of the time git
expects to be run from the place where the repo+worktree combination
is to be found. Anything else is a low-level configuration and is just
not expected to be used by people who aren't familiar with git's usage
of "worktree".
>
> >> It's clear (to me at least) that --work-tree should be used to
> >> identify the root of the working tree when not inside the working
> >> tree. I expected that the git directory would be automatically set to
> >> .git in the root of the working tree, as that would match the
> >> documentation. Instead, the current directory and its parents were
> >> checked -- which could provide dangerously misleading information to
> >> the user.
> >
> > What part of the documentation exactly? --work-tree tells git to look
> > for the working tree somewhere else. This option exists in order to
> > support a multiple-workdir workflow.
>
> What you mention above was what I was thinking about when I mentioned
> the possibility of this being a critical and significant feature. If
> it is important to support a workflow with one git directory and
> multiple working trees, and that case is more common/important than
> the one I experienced, then changing the behavior of --git-dir is
> obviously not the right thing to do.
It's not just about it being a critical feature. Yes it would break
many scripts, but what you want to do is meant to be done with a
subshell and I fail to see why git should go out of its way to support
such a usercase.
>
> >> I think that one of two things should be done: either the --git-dir
> >> default should be changed when the --work-tree option is set, or the
> >> error message cited above should be changed to explicitly identify the
> >> directory being tested as a potential git repository. I personally
> >
> > Git does tell you explicitly, but only when you specify a gitdir (via
> > GIT_DIR or --git-dir), otherwise it looks at the current directory.
>
> This is misleading if you don't know that the specification of a
> working tree does not also implicitly specify a git directory.
> Whether that lack of knowledge is the user's problem or the
> software/documentation's problem is a separate question.
The documentation now thankfully doesn't talk about working copy
anymore, so it should be fairly consistent. The gitglossary definition
of worktree should also explain what a worktree is.
>
> >> believe the first option is superior because it fulfills the
> >> expectations of average users (folks who read git's documentation
> >> instead of its source code) while permitting flexibility to those who
> >
> > It's not likely that it will get changed because that would break
> > backwards-compatability in a very big way. If your concern is for
> > "average user", she shouldn't be using that option, but changing to
> > that directory instead. If you want your working tree to be ./foo/ and
> > your gitdir to be ./foo/.git, why don't you just cd to ./foo/?
>
> From that perspective, why have --work-tree at all? Without that
> option, either the git directory is in the root of your current
> working tree, or it's not -- in which case --git-dir is all you need.
The reason for --work-tree (and the earlier GIT_WORKTREE) is to allow
you to temporarily set the worktree somewhere else. It's meant to tell
git to pretend $PWD is something else.
> If you're going to keep the option, it's helpful to provide the
> diagnostic output. My suggestion would be more compelling if I could
> provide a valid use case, but all I can come up with off the top of my
> head are scripts and something like "(cd $worktree && git status)"
> would probably work fine.
This subshell method is exactly how everyone's always written this
kind of thing, and the way that you're supposed to (and I don't mean
for git, I mean for any tool). Adding the option explicitly to git
would introduce an further potential source of bugs and is unnecessary.
>
> >> wish to refer to the current directory or some other directory
for
> >> their --git-dir value. If the current behavior is somehow not a bug
> >> but instead a critical and significant feature which if changed would
> >> cause more harm than good, please consider the second option.
> >
> > You get two different messages depending on how git is looking for the
> > repository. The message you mentioned gets printed when git tries to
> > find it automatically. A "fatal: Not a git repository: '/tmp'" gets
> > printed if you've told git to look for it in a specific place. The
> > information is already there, though I guess you do have to know about
> > the difference. Adding the current directory to the "default" message
> > probably wouldn't hurt, as it's unlikely that a script is parsing
> > that, and might be useful.
>
> Fewer scripts would be broken if the additional output is only
> displayed when --work-tree is used, but that might be too special-case
> for this situation.
That would connect unrelated code, I doubt it's reasonable.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: workflow for component based design (newbie to Git)
From: Frans Klaver @ 2011-12-01 12:53 UTC (permalink / raw)
To: Ivan Dimitrov; +Cc: git
In-Reply-To: <CAO8zR6N_kxQHA+Z=ruA5T8cc1A6km8Y3RouXib6oRXPWHzfA6A@mail.gmail.com>
On Thu, Dec 1, 2011 at 12:29 PM, Ivan Dimitrov <ivand58@gmail.com> wrote:
> Please forgive me for asking this, but I can't seem to find
> instructions anywhere.
>
> I'm planning to migrate from Serena PVCS to GIT, but I can't realize
> how to assign a label only to particular files (component) and how to
> apply the promotion model to my project with GIT ?
>
> So, in general, how one can handle a project with component based
> architecture (and workflow) with GIT?
In general one would have one repository per component (typically a
module). You can manage multiple repositories using git-submodule[1]
or an alternative tool like it. Labels are then tags for that
particular submodule. Labeling single files is not something git is
going to do, as it is tracking repository content rather than files.
Frans
[1] http://book.git-scm.com/5_submodules.html
^ permalink raw reply
* workflow for component based design (newbie to Git)
From: Ivan Dimitrov @ 2011-12-01 11:29 UTC (permalink / raw)
To: git
Hi all,
Please forgive me for asking this, but I can't seem to find
instructions anywhere.
I'm planning to migrate from Serena PVCS to GIT, but I can't realize
how to assign a label only to particular files (component) and how to
apply the promotion model to my project with GIT ?
So, in general, how one can handle a project with component based
architecture (and workflow) with GIT?
Thanks in advance.
^ permalink raw reply
* Re: [PATCH 4/3] revert: write REVERT_HEAD pseudoref during conflicted revert
From: Ramkumar Ramachandra @ 2011-12-01 9:34 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord,
Jay Soffian
In-Reply-To: <20111122111736.GE7399@elie.hsd1.il.comcast.net>
Hi,
Jonathan Nieder wrote:
> [...]
> Set a REVERT_HEAD pseudoref when "git revert" does not make a commit,
> for cases like this. This also makes it possible for scripts to
> distinguish between a revert that encountered conflicts and other
> sources of an unmerged index.
Sounds a lot like CHERRY_PICK_HEAD counterpart. Let's read ahead and
see if there are any unexpected differences.
> diff --git a/branch.c b/branch.c
> index d8098762..025a97be 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -241,6 +241,7 @@ void create_branch(const char *head,
> void remove_branch_state(void)
> {
> unlink(git_path("CHERRY_PICK_HEAD"));
> + unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
> unlink(git_path("MERGE_RR"));
> unlink(git_path("MERGE_MSG"));
> diff --git a/builtin/commit.c b/builtin/commit.c
> index c46f2d18..8f2bebec 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1514,6 +1514,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> }
>
> unlink(git_path("CHERRY_PICK_HEAD"));
> + unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
> unlink(git_path("MERGE_MSG"));
> unlink(git_path("MERGE_MODE"));
So far so good. Behaves exactly like CHERRY_PICK_HEAD.
> diff --git a/builtin/revert.c b/builtin/revert.c
> index 1d112e4c..f5ba67a5 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -289,7 +289,7 @@ static char *get_encoding(const char *message)
> return NULL;
> }
>
> -static void write_cherry_pick_head(struct commit *commit)
> +static void write_cherry_pick_head(struct commit *commit, const char *pseudoref)
> {
> const char *filename;
> int fd;
> @@ -297,7 +297,7 @@ static void write_cherry_pick_head(struct commit *commit)
>
> strbuf_addf(&buf, "%s\n", sha1_to_hex(commit->object.sha1));
>
> - filename = git_path("CHERRY_PICK_HEAD");
> + filename = git_path(pseudoref);
> fd = open(filename, O_WRONLY | O_CREAT, 0666);
> if (fd < 0)
> die_errno(_("Could not open '%s' for writing"), filename);
> @@ -597,7 +597,9 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
> * write it at all.
> */
> if (opts->action == CHERRY_PICK && !opts->no_commit && (res == 0 || res == 1))
> - write_cherry_pick_head(commit);
> + write_cherry_pick_head(commit, "CHERRY_PICK_HEAD");
> + if (opts->action == REVERT && ((opts->no_commit && res == 0) || res == 1))
> + write_cherry_pick_head(commit, "REVERT_HEAD");
>
> if (res) {
> error(opts->action == REVERT
Interesting. This additional symmetry will probably make life much
easier for my pending "New Sequencer Workflow! v2" series.
> diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
> index cb45574a..ee1659c1 100755
> --- a/t/t3507-cherry-pick-conflict.sh
> +++ b/t/t3507-cherry-pick-conflict.sh
> [...]
And some tests. Nice.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Luke Diamand @ 2011-12-01 8:31 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Vitor Antunes, git
In-Reply-To: <20111130230007.GA11598@arf.padd.com>
On 30/11/11 23:00, Pete Wyckoff wrote:
> P.S. Since you're respinning anyway to change the label code,
> can you stick the 'branch with shell char' test from t9801 in
> with t9803? It feels more appropriate there than with the branch
> tests. And avoids collision with some Vitor code that will get
> added eventually.
>
OK!
^ permalink raw reply
* Re: [PATCH v2 5/5] bulk-checkin: replace fast-import based implementation
From: Nguyen Thai Ngoc Duy @ 2011-12-01 8:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1322699263-14475-6-git-send-email-gitster@pobox.com>
On Thu, Dec 1, 2011 at 7:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> @@ -458,11 +459,15 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> free(seen);
> }
>
> + plug_bulk_checkin();
> +
> exit_status |= add_files_to_cache(prefix, pathspec, flags);
>
> if (add_new_files)
> exit_status |= add_files(&dir, flags);
>
> + unplug_bulk_checkin();
> +
> finish:
> if (active_cache_changed) {
> if (write_cache(newfd, active_cache, active_nr) ||
Also do the same for git-commit, except as-is commit case, for
updating large files?
update-index should also learn about this, although at plumbing level,
maybe we could have an option to let users choose what to stream (i.e.
skip size check for streaming).
--
Duy
^ 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