* Re: [PATCH] remote-curl: Fix push status report when all branches fail
From: Shawn Pearce @ 2012-01-20 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobtyhq16.fsf@alter.siamese.dyndns.org>
On Thu, Jan 19, 2012 at 22:00, Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> +cat >exp <<EOF
>> +remote: error: hook declined to update refs/heads/dev2
>
> Curious. Where do we get these eight trailing whitespaces?
I think this is padding being added to the end of the line by
recv_sideband(). I noticed the trailing whitespace in the diff, but
the test passed with it present, so I had to leave it in.
> The call to rp_error("hook declined to update %s", name) seems to be
> giving the name properly.
Yea, I think the server is sending the correct data in the sideband
channel, its just the sideband client padding out the line. I think
this padding is a fudge against progress meters that are being written
and over-written with \r lines in subsequent sideband packets.
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Carlos Martín Nieto @ 2012-01-20 15:53 UTC (permalink / raw)
To: mike; +Cc: git
In-Reply-To: <CADo4Y9iJyirdkEr1GCg9BD5rwX9=1uKptqHsiWB0_MiDKb_wUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4169 bytes --]
On Thu, 2012-01-19 at 15:02 -0500, Michael Nahas wrote:
> 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.
So your team has developed a VCS to run on top of the VCS you're using.
This is a bit disconcerting. What's the point of svn if you're tracking
the versions manually? Rolling back changes is one of the things that
svn is there to help you with. There is no need for an extra layer.
Separating production-ready changes with experimental changes is what
branches are for.
From the way you explain the development/deployment cycle, it doesn't
sound like any of the changes you dcommit should increase the version
number except for the last one. If you increase the version number three
times in one dcommit but you introduced the bug in the first of those,
now you have to manually go back and try each version, which seems
contrary to what the point of the scheme is.
cmn
>
> 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
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] remote-curl: Fix push status report when all branches fail
From: Thomas Rast @ 2012-01-20 16:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <CAJo=hJtCb=WFfuSKWvPk+S4sRQmSGemG_Ugqj+k1TZCOJj9vLQ@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> On Thu, Jan 19, 2012 at 22:00, Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>> +cat >exp <<EOF
>>> +remote: error: hook declined to update refs/heads/dev2
>>
>> Curious. Where do we get these eight trailing whitespaces?
>
> I think this is padding being added to the end of the line by
> recv_sideband(). I noticed the trailing whitespace in the diff, but
> the test passed with it present, so I had to leave it in.
ISTR we had a policy to guard such whitespace at EOL? Compare
e.g. c1376c12b7.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Autocompletion - commands no longer work as stand alone
From: Nathan Bullock @ 2012-01-20 16:32 UTC (permalink / raw)
To: git
In-Reply-To: <CAPx=Vfp_HVr5W1fFic_1k+JsKr2RAKd-RK=VkfSgo7qkb5GsAw@mail.gmail.com>
I have for a number of years had the following in my .bashrc
alias br="git branch"
complete -F _git_branch br
As well as similar commands for co and log.
Recently though this broke, now when I type something like "br
mas<command completion>" it will occasionally complain with messages
like:
bash: [: 1: unary operator expected
From digging through the source it looks like this was broken back in
April. (The commit is show at the bottom of this email.)
So my questions are:
1. Is it reasonable for things like _git_branch to work as a
standalone autocompletion function instead of having to go through
_git? I certainly like it to work as a standalone function. I also use
it to add autocompletion to other bash scripts that I use frequently.
2. If I add code that verifies that the variable cword exists at the
start of these functions and only if not call something like
_get_comp_words_by_ref -n =: cur words cword prev. Would that be
reasonable? I think this should address the performance concerns that
caused these to be removed in the first place, but it may make the
code uglier.
I have already added wrapper functions in my bashrc so that this is no
longer a problem for me, but there may be other people who start
hitting this as well once they start using newer versions of git.
Nathan
commit da4902a73017ad82b9926d03101ec69a2802d1e7
Author: SZEDER Gábor <szeder@ira.uka.de>
Date: Thu Apr 28 18:01:52 2011 +0200
completion: remove unnecessary _get_comp_words_by_ref() invocations
In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
to access completion-related variables. That was large change, and to
make it easily reviewable, we invoked _get_comp_words_by_ref() in each
completion function and systematically replaced every occurance of
bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
variables set by _get_comp_words_by_ref().
This has the downside that _get_comp_words_by_ref() is invoked several
times during a single completion. The worst offender is perhaps 'git
log mas<TAB>': during the completion of 'master'
_get_comp_words_by_ref() is invoked no less than six times.
However, the variables $prev, $cword, and $words provided by
_get_comp_words_by_ref() are not modified in any of the completion
functions, and the previous commit ensures that the $cur variable is
not modified as well. This makes it possible to invoke
_get_comp_words_by_ref() to get those variables only once in our
toplevel completion functions _git() and _gitk(), and all other
completion functions will inherit them.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* [PATCH] remote-curl: Fix push status report when all branches fail
From: Shawn O. Pearce @ 2012-01-20 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <8739bacpql.fsf@thomas.inf.ethz.ch>
From: "Shawn O. Pearce" <spearce@spearce.org>
The protocol between transport-helper.c and remote-curl requires
remote-curl to always print a blank line after the push command
has run. If the blank line is ommitted, transport-helper kills its
container process (the git push the user started) with exit(128)
and no message indicating a problem, assuming the helper already
printed reasonable error text to the console.
However if the remote rejects all branches with "ng" commands in the
report-status reply, send-pack terminates with non-zero status, and
in turn remote-curl exited with non-zero status before outputting
the blank line after the helper status printed by send-pack. No
error messages reach the user.
This caused users to see the following from git push over HTTP
when the remote side's update hook rejected the branch:
$ git push http://... master
Counting objects: 4, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
$
Always print a blank line after the send-pack process terminates,
ensuring the helper status report (if it was output) will be
correctly parsed by the calling transport-helper.c. This ensures
the helper doesn't abort before the status report can be shown to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
remote-curl.c | 9 +++++----
t/t5541-http-push.sh | 27 +++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 48c20b8..25c1af7 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -805,7 +805,7 @@ static int push(int nr_spec, char **specs)
static void parse_push(struct strbuf *buf)
{
char **specs = NULL;
- int alloc_spec = 0, nr_spec = 0, i;
+ int alloc_spec = 0, nr_spec = 0, i, ret;
do {
if (!prefixcmp(buf->buf, "push ")) {
@@ -822,12 +822,13 @@ static void parse_push(struct strbuf *buf)
break;
} while (1);
- if (push(nr_spec, specs))
- exit(128); /* error already reported */
-
+ ret = push(nr_spec, specs);
printf("\n");
fflush(stdout);
+ if (ret)
+ exit(128); /* error already reported */
+
free_specs:
for (i = 0; i < nr_spec; i++)
free(specs[i]);
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 9b85d42..c68cbf3 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -95,6 +95,31 @@ test_expect_success 'create and delete remote branch' '
test_must_fail git show-ref --verify refs/remotes/origin/dev
'
+cat >"$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update" <<EOF
+#!/bin/sh
+exit 1
+EOF
+chmod a+x "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
+
+printf 'remote: error: hook declined to update refs/heads/dev2 \n' >exp
+cat >>exp <<EOF
+To http://127.0.0.1:$LIB_HTTPD_PORT/smart/test_repo.git
+ ! [remote rejected] dev2 -> dev2 (hook declined)
+error: failed to push some refs to 'http://127.0.0.1:5541/smart/test_repo.git'
+EOF
+
+test_expect_success 'rejected update prints status' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ git checkout -b dev2 &&
+ : >path4 &&
+ git add path4 &&
+ test_tick &&
+ git commit -m dev2 &&
+ git push origin dev2 2>act
+ test_cmp exp act
+'
+rm -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
+
cat >exp <<EOF
GET /smart/test_repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
@@ -106,6 +131,8 @@ GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
+GET /smart/test_repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
+POST /smart/test_repo.git/git-receive-pack HTTP/1.1 200
EOF
test_expect_success 'used receive-pack service' '
sed -e "
--
1.7.9.rc2.124.g1c075
^ permalink raw reply related
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-20 18:03 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <87mx9icz28.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>> 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".
>
> I don't understand what distinction you are trying to make here. Maybe
> my mental model of the plumbing/porcelain separation (which is mostly
> about interface stability) is wrong?
What's so hard to understand that these tests are very different from
end-user scripts?
We could have shipped you a written instruction to type these commands
from your shell and made you responsible for running them every time we
release a new version. That would have been more true to the intent of
these test scripts. The test being implemented as scripts is merely a
substitute for hiring one Thomas Rast as a test engineer to type them from
the terminal ;-).
User-facing scripts (Porcelain enhancements) people write are in a totally
different boat. They take input and have code to make their own decision
what kind of arguments and inputs to feed to their underlying building
blocks. They may even parse output from the commands they invoke to base
their decision that affects what happens next. Our tests start from a
known state (i.e. empty trash directory), take input from neither command
line, human interaction nor the filesystem content of the day, that affect
the input to the commands they drive.
To put it another way, if you have a cron job that does
cd $HOME/diary && git add MyDiary.txt
that is perfectly fine. You are letting the machine do the typing for you
every hour, instead of having you type these yourself. It is even OK if
the filename was derived from `date` or something, i.e.
N=$(date +'%Y-%m-%d').txt &&
if test -f "$N"
then
git add "$N"
fi
What is not OK is to attempt parsing from Porcelain output to decide what
to do next. "git branch | sed -ne 's/^\* //p'" is a typical example.
Our tests are different for another important reason you seem to be
missing. The tests we ship are tied very closely with the version of Git
they are testing. Even parsing the command output is acceptable for our
tests for this reason (obviously that is the only way to make sure that we
are issuing an appropriate error, warning, or advice message to the end
user). End-user scripts do not have that property.
And the biggest thing you should consider is that 99% of users are too
busy to bother thinking for themselves and instead prefer to be handed
down a concise recipe to follow blindly. You could include "in this, that,
and that other situation, it is OK to use Porcelain command" to the
recipe, but doing so defeats the whole purpose of having a recipe to begin
with, by making the readers responsible for thinking for themselves again.
That is why we just give a concise "Do not use Porcelain commands in your
scripts as their behaviour is subject to change."
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: David Brown @ 2012-01-20 18:06 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Brian Foster, git mailing list
In-Reply-To: <m2ehuu8nrt.fsf@igel.home>
On Fri, Jan 20, 2012 at 03:13:58PM +0100, Andreas Schwab wrote:
> Brian Foster <brian.foster@maxim-ic.com> writes:
>
> > In a script, how can I determine commit Y is reachable
> > from the current HEAD ?
>
> test $(git merge-base HEAD Y) = $(git rev-parse Y)
Almost. It works as long as there is only one merge base. You really
need to check if $(git rev-parse Y) is one of $(git merge-base --all
HEAD Y)
if HEAD is a named branch, you can do
git name-rev --refs=refs/heads/branchname Y
which will give you Y relative to branchname if it is contained within
it.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [BUG] Git bisect not finding the right commit
From: Junio C Hamano @ 2012-01-20 18:09 UTC (permalink / raw)
To: git; +Cc: Andreas J. Koenig
In-Reply-To: <87ehuu958d.fsf@franz.ak.mind.de>
andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:
>>>>>> On Thu, 19 Jan 2012 09:23:01 +0100, Johannes Sixt <j.sixt@viscovery.net> said:
>
> js> Am 1/19/2012 4:29, schrieb Andreas J. Koenig:
> >> - A -> B -> C - D ->
> >> \ /
> >> - E - F -
> >>
> >> A v5.15.5
> >> B v5.15.5-20-gfd76d40
> >> C v5.15.5-81-gcfe287a
> >> D v5.15.5-159-ga71d67b
> >> E v5.15.4-110-g27b29ec
> >> F v5.15.4-169-g3582575
>
> js> I haven't looked at the actual history, but given the names of the commits
> js> as produced by git-describe, I doubt that your history graph sketched
> js> above is correct. Doesn't it look more like this:
>
> js> A -- B -- C -- D --
> js> / /
> js> -- X -- E -- F
>
> js> where X is v5.15.4?
>
> Yes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58
> and since there was a long timespan between the start of the development
> of the code and the merge (May-Nov), the gitk presentation got a bit
> complex to read.
(This is somewhat off-topic, so Andreas is on Cc: and the list is on To:)
I doubt --simplify-by-decoration alone would make it easier to view such a
complex and long history, but I wonder if we can use the same logic to
help users in a case like this. Instead of only keeping tagged versions in
the result to show topology, perhaps we can allow the user to feed a list
of "key points in history" as command line arguments and apply the same
kind of simplification to help visualizing the topology?
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Dieter Plaetinck @ 2012-01-20 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk44nidtb.fsf@alter.siamese.dyndns.org>
On Thu, 19 Jan 2012 13:26:40 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> 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.
I don't understand what you mean. if this happened:
1) modify file
2) modify file
3) remove file
but my script tries to git add --ignore-missing, when 3) already happened
but the script only sees event 2)
then it will not fail, then catch the 3rd event, then do a git rm.
if however, i don't enable ignore-missing, there's a failure on the git add.
I guess what you're saying is "better to get an error, interpret it as `this may not be a "real" error`, just continue"
>
> 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).
I assumed that `git add` works atomically. (as in: if you git add a file and
modify that file at the same time, either the old or the new version will be added
to the index, but always successfully).
If I understand this correctly, `git add` can only be successful if at least the file
remains untouched while the git command runs.
This means I should change my entire approach and be aware that git may return failures when the user is changing files while we are adding to the index.
Maybe I should do something like:
once >0 inotify events happened,
* run git status, for each file in git status, if we've seen events, try to add file to the index.
if the above fails, wait a few seconds, then try again. if failures persist a few times in a row, only then we can be reasonbly sure something is really wrong.
but there will always be the case where a file gets deleted and (re)added, there is always the risk for races:
1) my script runs "git rm" after seeing a "delete" event but the file has been added in the meanwhile... git removes the file => bad
2) my script runs "git add" after seeing a new/changed file but the file has been removed in the meanwhile... git gives an error.
and in the latter case you can't just apply the "just retry" trick I mentioned above because the next event is delete, which would trigger a "git rm",
potentially causing unrecoverable data loss as described in 1).
one example of such things happening in real life is vim which creates (and removes) tmp files called `4913`.
We could just add such filenames to gitignore,
but that seems like a bit of a burden which shouldn't be needed.
To avoid the risks mentioned above and the "file can be altered during git add command",
what i'm really looking for is a way to, for a given file (file for which I've seen inotify events):
synchronize changes of that file to the index even if the file was unknown to git, or doesn't exist anymore;
and do that in an atomic way (or: i'll just retry a few times until it fails consistently, but removal race conditions can lead to data loss)
I tried `git update-index` as you suggested but couldn't have it behave like that.
And something like `git add --all` can still cause a file removal when it shouldn't, and lead to uncoverable data loss on race conditions.
Sorry for the long mail, I tried to keep it as minimal as possible.
thanks!
Dieter
^ permalink raw reply
* Re: [PATCH] remote-curl: Fix push status report when all branches fail
From: Junio C Hamano @ 2012-01-20 18:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1327079011-24788-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Always print a blank line after the send-pack process terminates,
> ensuring the helper status report (if it was output) will be
> correctly parsed by the calling transport-helper.c. This ensures
> the helper doesn't abort before the status report can be shown to
> the user.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
Thanks; let's do the following on top of this patch, so that:
- We won't miss a "git push" that errorneously succeeds; and
- We won't be affected by any future change in the sideband #2
demultiplexor of the amount of "padding".
t/t5541-http-push.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git b/t/t5541-http-push.sh a/t/t5541-http-push.sh
index d3e340e..b8f4c2a 100755
--- b/t/t5541-http-push.sh
+++ a/t/t5541-http-push.sh
@@ -101,8 +101,8 @@ exit 1
EOF
chmod a+x "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
-printf 'remote: error: hook declined to update refs/heads/dev2 \n' >exp
-cat >>exp <<EOF
+cat >exp <<EOF
+remote: error: hook declined to update refs/heads/dev2
To http://127.0.0.1:$LIB_HTTPD_PORT/smart/test_repo.git
! [remote rejected] dev2 -> dev2 (hook declined)
error: failed to push some refs to 'http://127.0.0.1:5541/smart/test_repo.git'
@@ -115,8 +115,9 @@ test_expect_success 'rejected update prints status' '
git add path4 &&
test_tick &&
git commit -m dev2 &&
- git push origin dev2 2>act
- test_cmp exp act
+ test_must_fail git push origin dev2 2>act &&
+ sed -e "/^remote: /s/ *$//" <act >cmp &&
+ test_cmp exp cmp
'
rm -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
^ permalink raw reply related
* Re: [PATCH v3] mergetool: Provide an empty file when needed
From: Junio C Hamano @ 2012-01-20 18:28 UTC (permalink / raw)
To: Jason Wenger; +Cc: David Aguilar, git
In-Reply-To: <CAM6z=4-HfRAjJjnYqfoiYsYjiZJSsbkCaW-VtLWvoeFM0xsB9g@mail.gmail.com>
Jason Wenger <jcwenger@gmail.com> writes:
> On Fri, Jan 20, 2012 at 01:53, David Aguilar <davvid@gmail.com> wrote:
>> On Thu, Jan 19, 2012 at 11:47 PM, David Aguilar <davvid@gmail.com> wrote:
>>> Some merge tools cannot cope when $LOCAL, $BASE, or $REMOTE
>>> are missing. $BASE can be missing when two branches
>>> independently add the same filename. $LOCAL and $REMOTE
>>> can be missing when a delete/modify conflict occurs.
>>>
>>> Provide an empty file to make these tools happy.
>
> This is cleaner, yes -- but is this extra processing on $LOCAL and
> $REMOTE necessary? Git mergetool doesn't actually call an external
> mergetool during del/mod conflicts -- instead it goes into an
> alternate processing and prompts the user interactively whether to
> take the deleted or modified file. Can these changes be reached?
> (command line option I'm not aware of?)
Thanks for a careful reading. I did not read outside the context of the
patch so I didn't know if we had special cases for del/mod.
A bigger question is if the del/mod codepaths are negatively affected by
the presense of these superfluous empty $LOCAL/$REMOTE files. If they are,
this change will _break_ things. If they are not, I think the change would
be OK.
Another small worry is that this could potentially negatively affect some
merge tools that are sufficiently clueful, if it can give different and
better results for a true two-way-merge than a simulated two-way-merge
this patch feeds them by using a three-way-merge with an empty file as a
base.
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Junio C Hamano @ 2012-01-20 19:18 UTC (permalink / raw)
To: David Brown; +Cc: Andreas Schwab, Brian Foster, git mailing list
In-Reply-To: <20120120180620.GA8504@codeaurora.org>
David Brown <davidb@codeaurora.org> writes:
> On Fri, Jan 20, 2012 at 03:13:58PM +0100, Andreas Schwab wrote:
>> Brian Foster <brian.foster@maxim-ic.com> writes:
>>
>> > In a script, how can I determine commit Y is reachable
>> > from the current HEAD ?
>>
>> test $(git merge-base HEAD Y) = $(git rev-parse Y)
>
> Almost. It works as long as there is only one merge base. You really
> need to check if $(git rev-parse Y) is one of $(git merge-base --all
> HEAD Y)
Can you give us an example of a topology to which "merge-base --all HEAD Y"
gives more than one output and Y is still reachable from HEAD?
It is my understanding that merge-base computation will give only Y and
nothing else when Y is reachable from HEAD. I also think this assumption
is used by some of the internal code in Git, and that is why I care.
^ permalink raw reply
* Re: Autocompletion - commands no longer work as stand alone
From: Junio C Hamano @ 2012-01-20 19:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Nathan Bullock, git
In-Reply-To: <CAPx=Vfqj3UZuFv3Xmupy7k9arUxyZJyprm628p9QVKabdOz8cw@mail.gmail.com>
Pinging Szeder. I personally do not think it is a crime for us to break
anything that uses an internal function whose name begins with underscore,
but people more deeply involved in this part of the system may have ideas
to help supporting even such users.
Nathan Bullock <nathanbullock@gmail.com> writes:
> I have for a number of years had the following in my .bashrc
>
> alias br="git branch"
> complete -F _git_branch br
>
> As well as similar commands for co and log.
>
> Recently though this broke, now when I type something like "br
> mas<command completion>" it will occasionally complain with messages
> like:
> bash: [: 1: unary operator expected
>
> From digging through the source it looks like this was broken back in
> April. (The commit is show at the bottom of this email.)
>
> So my questions are:
> 1. Is it reasonable for things like _git_branch to work as a
> standalone autocompletion function instead of having to go through
> _git? I certainly like it to work as a standalone function. I also use
> it to add autocompletion to other bash scripts that I use frequently.
>
> 2. If I add code that verifies that the variable cword exists at the
> start of these functions and only if not call something like
> _get_comp_words_by_ref -n =: cur words cword prev. Would that be
> reasonable? I think this should address the performance concerns that
> caused these to be removed in the first place, but it may make the
> code uglier.
>
> I have already added wrapper functions in my bashrc so that this is no
> longer a problem for me, but there may be other people who start
> hitting this as well once they start using newer versions of git.
>
> Nathan
>
>
> commit da4902a73017ad82b9926d03101ec69a2802d1e7
> Author: SZEDER Gábor <szeder@ira.uka.de>
> Date: Thu Apr 28 18:01:52 2011 +0200
>
> completion: remove unnecessary _get_comp_words_by_ref() invocations
>
> In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
> with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
> to access completion-related variables. That was large change, and to
> make it easily reviewable, we invoked _get_comp_words_by_ref() in each
> completion function and systematically replaced every occurance of
> bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
> variables set by _get_comp_words_by_ref().
>
> This has the downside that _get_comp_words_by_ref() is invoked several
> times during a single completion. The worst offender is perhaps 'git
> log mas<TAB>': during the completion of 'master'
> _get_comp_words_by_ref() is invoked no less than six times.
>
> However, the variables $prev, $cword, and $words provided by
> _get_comp_words_by_ref() are not modified in any of the completion
> functions, and the previous commit ensures that the $cur variable is
> not modified as well. This makes it possible to invoke
> _get_comp_words_by_ref() to get those variables only once in our
> toplevel completion functions _git() and _gitk(), and all other
> completion functions will inherit them.
>
> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: Autocompletion - commands no longer work as stand alone
From: Nathan Bullock @ 2012-01-20 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, git
In-Reply-To: <7vwr8mdvo8.fsf@alter.siamese.dyndns.org>
So just as a comment on the use of underscores. The actual main auto
complete function, _git, also starts with an underscore. From looking
at the code it looked like the double underscore functions were the
internal ones.
2012/1/20 Junio C Hamano <gitster@pobox.com>:
> Pinging Szeder. I personally do not think it is a crime for us to break
> anything that uses an internal function whose name begins with underscore,
> but people more deeply involved in this part of the system may have ideas
> to help supporting even such users.
>
> Nathan Bullock <nathanbullock@gmail.com> writes:
>
>> I have for a number of years had the following in my .bashrc
>>
>> alias br="git branch"
>> complete -F _git_branch br
>>
>> As well as similar commands for co and log.
>>
>> Recently though this broke, now when I type something like "br
>> mas<command completion>" it will occasionally complain with messages
>> like:
>> bash: [: 1: unary operator expected
>>
>> From digging through the source it looks like this was broken back in
>> April. (The commit is show at the bottom of this email.)
>>
>> So my questions are:
>> 1. Is it reasonable for things like _git_branch to work as a
>> standalone autocompletion function instead of having to go through
>> _git? I certainly like it to work as a standalone function. I also use
>> it to add autocompletion to other bash scripts that I use frequently.
>>
>> 2. If I add code that verifies that the variable cword exists at the
>> start of these functions and only if not call something like
>> _get_comp_words_by_ref -n =: cur words cword prev. Would that be
>> reasonable? I think this should address the performance concerns that
>> caused these to be removed in the first place, but it may make the
>> code uglier.
>>
>> I have already added wrapper functions in my bashrc so that this is no
>> longer a problem for me, but there may be other people who start
>> hitting this as well once they start using newer versions of git.
>>
>> Nathan
>>
>>
>> commit da4902a73017ad82b9926d03101ec69a2802d1e7
>> Author: SZEDER Gábor <szeder@ira.uka.de>
>> Date: Thu Apr 28 18:01:52 2011 +0200
>>
>> completion: remove unnecessary _get_comp_words_by_ref() invocations
>>
>> In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
>> with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
>> to access completion-related variables. That was large change, and to
>> make it easily reviewable, we invoked _get_comp_words_by_ref() in each
>> completion function and systematically replaced every occurance of
>> bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
>> variables set by _get_comp_words_by_ref().
>>
>> This has the downside that _get_comp_words_by_ref() is invoked several
>> times during a single completion. The worst offender is perhaps 'git
>> log mas<TAB>': during the completion of 'master'
>> _get_comp_words_by_ref() is invoked no less than six times.
>>
>> However, the variables $prev, $cword, and $words provided by
>> _get_comp_words_by_ref() are not modified in any of the completion
>> functions, and the previous commit ensures that the $cur variable is
>> not modified as well. This makes it possible to invoke
>> _get_comp_words_by_ref() to get those variables only once in our
>> toplevel completion functions _git() and _gitk(), and all other
>> completion functions will inherit them.
>>
>> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-20 19:35 UTC (permalink / raw)
To: Alex Riesen
Cc: Ævar Arnfjörð Bjarmason, Johannes Sixt,
Git Mailing List
In-Reply-To: <CALxABCZWBtgX736Acoy-CCAz8RJb0EKnHf+7g72dOdVS+BOhSw@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>> And then a --version for whatever programs that function uses,
>> e.g. here:
>>
>> $ envsubst --version
>
> Nothing. Exit code 127.
Interesting.
$ wonbsubst --version; echo $?
bash: wonbsubst: command not found
127
Perhaps your distro lacks a necessary package dependencies between gettext
and envsubst?
> I believe gettext (the binary) just doesn't start at all here. Maybe
> some Cygwin library wrong or missing library. Happens all the time
> here,...
Aha.
I guess we either leave it broken for broken installation or add an extra
"MY_GETTEXT_IS_BROKEN" option; in either way, it does not sound like a
serious enough issue that is widespread to be urgently fixed during the
feature freeze.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-20 19:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð, Johannes Sixt, Git Mailing List
In-Reply-To: <7vsjjadv5g.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 20:35, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>> And then a --version for whatever programs that function uses,
>>> e.g. here:
>>>
>>> $ envsubst --version
>>
>> Nothing. Exit code 127.
>
> Interesting.
>
> $ wonbsubst --version; echo $?
> bash: wonbsubst: command not found
> 127
>
> Perhaps your distro lacks a necessary package dependencies between gettext
> and envsubst?
>
>> I believe gettext (the binary) just doesn't start at all here. Maybe
>> some Cygwin library wrong or missing library. Happens all the time
>> here,...
>
> Aha.
>
> I guess we either leave it broken for broken installation or add an extra
> "MY_GETTEXT_IS_BROKEN" option; in either way, it does not sound like a
> serious enough issue that is widespread to be urgently fixed during the
> feature freeze.
Ævar already posted a very cute little fix for this, which looks
pretty minimal and is very obvious.
P.S. Sorry for html mail before (tried to use the Android Gmail client).
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Junio C Hamano @ 2012-01-20 20:00 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Alex Riesen, Johannes Sixt
In-Reply-To: <1327063775-28420-1-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Here's a minimal patch to git-sh-i18n that should make things work on
> Cygwin and any other platforms with broken gettext functions while
> also using the OS-provided functions if they work.
> I've added a new t0201-gettext-fallbacks-broken-gettext.sh test that
> tests this. This required a small change in lib-gettext.sh so I
> wouldn't load test-lib.sh twice.
>
> Note that there's already a t0201* test in the repo. Maybe we want to
> increment all the gettext test numbers by one to make room for it?
>
> As an aside I'm really not a big fan of having hardcoded numbers in
> the test files like this. We don't care about the order of execution
> here.
We do not care the order but we do care about the uniqueness in parallel
test execution.
It does appear that we need a bit better preprocessing of git-sh-i18n at
the compile time now. How about applying the restructuring shown in the
patch by Alex (without the @@NO_GETTEXT@@ bit) first without changing any
logic, then try making the "First decide what scheme to use" part lighter
weight by replacing the runtime "type gettext.sh" and such checks with
some preprocessing?
IOW, the first step would look like the attached patch, and then we can
replace the entire "First decide" part if/elif/fi chain with just this:
# The scheme to use
: ${GIT_INTERNAL_GETTEXT_SH_SCHEME:=@@GETTEXT_SH_SCHEME@@}
so that t/lib-gettext.sh can define and export GIT_INTERNAL_GETTEXT_SH to
always get what it wants to test (fallthrough?). At build time, instead
of, or in addition to, the $(cmd_munge_script), we could replace the
single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
use to hardcode the decision we make at the compile time.
Hmm?
git-sh-i18n.sh | 103 +++++++++++++++++++++++++++-----------------------------
1 files changed, 50 insertions(+), 53 deletions(-)
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index 26a57b0..6648bd3 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -16,61 +16,45 @@ else
fi
export TEXTDOMAINDIR
-if test -z "$GIT_GETTEXT_POISON"
+# First decide what scheme to use...
+GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
+if test -n "$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 && test "$(gettext test 2>&1)" = "test"
- 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
+ # GNU libintl's gettext.sh
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
+elif test "$(gettext -h 2>&1)" = "-h"
+then
+ # gettext binary exists but no gettext.sh. likely to be a gettext
+ # binary on a Solaris or something that is not GNU libintl and
+ # lack eval_gettext.
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gettext_without_eval_gettext
+fi
+export GIT_INTERNAL_GETTEXT_SH_SCHEME
+# ... and then follow that decision.
+case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
+gnu)
+ # Use libintl's gettext.sh, or fall back to English if we can't.
+ . gettext.sh
+ ;;
+gettext_without_eval_gettext)
+ # 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)
+ # Emit garbage so that tests that incorrectly rely on translatable
+ # strings will fail.
gettext () {
printf "%s" "# GETTEXT POISON #"
}
@@ -78,7 +62,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 () {
^ permalink raw reply related
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Alex Riesen @ 2012-01-20 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <7vobtydu0o.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 21:00, Junio C Hamano <gitster@pobox.com> wrote:
> IOW, the first step would look like the attached patch, and then we can
> replace the entire "First decide" part if/elif/fi chain with just this:
>
> # The scheme to use
> : ${GIT_INTERNAL_GETTEXT_SH_SCHEME:=@@GETTEXT_SH_SCHEME@@}
>
> so that t/lib-gettext.sh can define and export GIT_INTERNAL_GETTEXT_SH to
> always get what it wants to test (fallthrough?). At build time, instead
> of, or in addition to, the $(cmd_munge_script), we could replace the
> single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
> use to hardcode the decision we make at the compile time.
I can imagine a Solaris system being upgraded to GNU gettext _after_ Git
installation. Hardcoding the decision might break git scripts then.
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Junio C Hamano @ 2012-01-20 20:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <CALxABCZJATyVRf9akmfpn3WpJ8Xt80Ky0isFOTwDGpFKvFp3nw@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>> ... At build time, instead
>> of, or in addition to, the $(cmd_munge_script), we could replace the
>> single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
>> use to hardcode the decision we make at the compile time.
>
> I can imagine a Solaris system being upgraded to GNU gettext _after_ Git
> installation. Hardcoding the decision might break git scripts then.
Just like you would break http transport by removing libcurl after
installing Git? What else is new?
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Alex Riesen @ 2012-01-20 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <7vfwfadt10.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 21:21, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>> ... At build time, instead
>>> of, or in addition to, the $(cmd_munge_script), we could replace the
>>> single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
>>> use to hardcode the decision we make at the compile time.
>>
>> I can imagine a Solaris system being upgraded to GNU gettext _after_ Git
>> installation. Hardcoding the decision might break git scripts then.
>
> Just like you would break http transport by removing libcurl after
> installing Git? What else is new?
Removing - yes, upgrading it - very unlikely. Besides, the current version
wont have problems with such an upgrade.
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Junio C Hamano @ 2012-01-20 20:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <CALxABCZnz-8BuXf=-HrH7UZXi6pQ3VzL4HrOKgKHqWwUMnwJQA@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> .... Besides, the current version
> wont have problems with such an upgrade.
Yes, but at what cost?
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Alex Riesen @ 2012-01-20 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <7vbopydst0.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 21:26, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> .... Besides, the current version
>> wont have problems with such an upgrade.
>
> Yes, but at what cost?
A fixed number of "fork and exec" for every executed ". git-sh-i18n" line?
The overhead might be considered negligible...
Er. Am I missing something very obvious? (not obvious to me, yet)
^ permalink raw reply
* Finding all commits which modify a file
From: Neal Groothuis @ 2012-01-20 21:35 UTC (permalink / raw)
To: git
Hello,
I'm trying to find /all/ commits that change a file in the
repository...and its proving to be trickier than I thought. :-)
The situation that we were dealing with is this:
- Person A and person B both pull from the same central repository.
- Person A makes a change to file foo.txt and bar.txt, commits, and pushes
to the central repository.
- Person B makes a similar change to bar.txt and commits it.
- Person B does a fetch and merge. Since both A and B made changes to
bar.txt, this requires conflicts to be resolved manually.
- B reverts A's changes to foo.txt. (If B is coming from a different
revision control system, this may happen due to confusion about how merges
are handled.)
- B commits the changes.
- B makes more changes to bar.txt, commits them, and pushes to the central
repository.
At this point, A's changes to foo.txt have been undone.
Graphically:
A1
/ ^
v \
C1 B2<-B3
^ /
\ v
B1
B1, B2, and B3 have the same version of foo.txt as C1, A1 modifies it.
Person A discovers that his changes are missing and wants to know what
happened.
git log foo.txt doesn't help; it won't even show commit A1, due to history
simplification.
git log --full-history foo.txt will show commit A1. It still won't show
commit B2, though, which we'd also like to show (because that's where the
change to foo.txt got removed).
I would think that git log --simplify-merges foo.txt would have done what
I'd wanted, but it still does not show commit B2. Based on what I'm
reading in the man page, I would expect the simplification to go like
this:
A1
| ^
| \
| B2<-B3
| /
v v
C1
(since B1 is TREESAME as C1 if we're only considering foo.txt)
A1
| ^
| \
| B2<-B3
|
v
C1
(since C1 is an ancestor of A1)
However, the actual output only includes A1, not B2.
- Can someone explain this, and/or
- can someone offer a command to display all commits (including merges)
in which ANY parent is not TREESAME?
Thanks!
- Neal
^ permalink raw reply
* git clone, hardlinks and multiple users?
From: Marc Herbert @ 2012-01-20 17:31 UTC (permalink / raw)
To: git
Hi,
"git clone" is using hardlinks by default, even when cloning from a
different user. In such a case the clone ends up with a number of files
owned by someone else.
Since only immutable objects are cloned this seems to work fine. However
I would like to know if this "multiple users" case works by chance or by
specification.
In other words, is there a guarantee that no later version of git or no
obscure option I haven't used yet will ever try to touch a hardlink in
any way like for instance: trying update some metadata timestamp or,
overwrite it with the same value by lack of optimization, or any other
kind of side-effect that would obviously fail.
Thanks in advance!
Marc
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Sitaram Chamarty @ 2012-01-20 22:50 UTC (permalink / raw)
To: Brian Foster; +Cc: git mailing list
In-Reply-To: <201201201433.30267.brian.foster@maxim-ic.com>
On Fri, Jan 20, 2012 at 7:03 PM, Brian Foster <brian.foster@maxim-ic.com> wrote:
>
> Hello,
>
> Whilst I have found answers to my question on the Web,
> only one seems to do exactly what I want ....
>
> x---Y---y---y---y HEAD
> /
> ...--o---o---C---o---S
> \
> n---n---N---*---* other
>
> In a script, how can I determine commit Y is reachable
> from the current HEAD ? And, much more importantly
I've been using 'git rev-list HEAD..Y'. If it produces any output, Y
is not reachable from HEAD (there is something in Y that is not in
HEAD).
^ 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