* Re: [HELP] Adding git awareness to the darning patch management system.
From: Peter Williams @ 2011-11-30 23:47 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <CALUzUxrcWB62jARtgifTOocGL4gEGXDFMiO=ppHXzFyUmb+3ww@mail.gmail.com>
On 30/11/11 19:04, Tay Ray Chuan wrote:
> On Wed, Nov 30, 2011 at 10:17 AM, Peter Williams
> <peter_ono@users.sourceforge.net> wrote:
>> I'm the author of the darning patch management system
>> <http://darning.sourceforge.net/> and would like some help adding git
>> awareness to the system. At this stage of the development, "awareness" is
>> fairly simple concept with two broad aims:
>
> That link says it "combines the strengths of quilt and mq and
> eliminates their weaknesses", but I don't see any info on why this is
> the case with your program;
Documenting this is on my todo list (but not at the top).
Quilt's weaknesses are documented on their website and my issues with MQ
is that it (potentially) compromises the Mercurial repository and others
to which it may push. (MQ also has the problem that its current
maintainers don't understand the workflow for which it was designed and
are changing it to suit a different workflow.)
The repository compromise issue also applies to stgit.
Other things darning adds are:
1. tracking of copies and renames (not in quilt),
2. tracking changes to files' modes (not in quilt),
3. binary diffs (using git binary diff format for import/export), and
4. help managing addition of trailing whitespace by patches.
> it would be great it if you could provide
> a quick start guide (probably easier to show this with some commands
> in the CLI rather than GUI screenshots).
At this stage, the CLI is really only there to allow me to do script
based testing of darning's internals and is not a fully capable
interface. However, if you look in the directory test-cli for files
with a ".test" suffix you will find examples of their use.
>
> Have a look at StGit's tutorial
> http://www.procode.org/stgit/doc/tutorial.html (very similar to quilt
> and mq too) to see what I mean.
OK
Peter
^ permalink raw reply
* [PATCH] git-svn.perl: close the edit for propedits even with no mods
From: Steven Walter @ 2011-12-01 2:37 UTC (permalink / raw)
To: rmalperson, git; +Cc: Steven Walter
It's legitimate to update the mergeinfo property without
actually changing any files. This can happen when changes are
backported to a branch, and then that branch is merged back
into mainline. We still want to record the updated mergeinfo
for book-keeping.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 177dd25..cd64659 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4867,7 +4867,7 @@ sub apply_diff {
$self->{mergeinfo});
}
$self->rmdirs if $_rmdir;
- if (@$mods == 0) {
+ if (@$mods == 0 && !defined($self->{mergeinfo})) {
$self->abort_edit;
} else {
$self->close_edit;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Pete Wyckoff @ 2011-12-01 4:02 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Luke Diamand, git
In-Reply-To: <CAOpHH-U3PF0v7EPqnO0FNxNKh+uF1GH=cnA_MA09SaQTxo0cDA@mail.gmail.com>
vitor.hda@gmail.com wrote on Thu, 01 Dec 2011 00:33 +0000:
> On Wed, Nov 30, 2011 at 10:58 PM, Pete Wyckoff <pw@padd.com> wrote:
> > This is another fundamental disconnect between p4 and git.
> > Reading
> >
> > http://www.perforce.com/perforce/doc.current/manuals/p4guide/07_labels.html
> >
> > it is clear that labels are supposed to be used exactly where
> > tags cannot: to specify a collection of files as they existed
> > at _different_ points in the commit history.
>
> Check the "Use Tag Fixup Branches" section in fast-import manual, it
> might help on this. The basic concept is to create a special branch
> that puts all files in the same state the P4 label would put them and
> then tag it in git.
>
> Tried to use this for my branch stuff, but with no success.
Interesting, thanks. One could certainly construct any arbitrary
tree to represent the tag. But it would be a truly evil merge of
possibly many commits.
> > Thus I think supporting labels is kind of pointless. But in the
> > restricted use case that perforce docs tell us not to do, namely
> > using labels to identify change numbers, git can reflect that
> > with tags.
>
> I still use labels as simple tags. Telling that we should use
> changelists instead of labels is the same as saying that we should use
> IP addresses instead of host names. It works, but I doubt you will
> ever remember it unless you write it down somewhere.
I see your point. P4 labels are the only way that they support
tagging, apparently. I'm okay with leaving label support in
git-p4. And it will be nice if Luke makes it behave a bit
better. But doing heroics to emulate cross-commit tags feels
like a lot of work, and the wrong direction.
-- Pete
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Nguyen Thai Ngoc Duy @ 2011-12-01 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Bill Zaumen, git, spearce, torvalds
In-Reply-To: <7vzkfdqye3.fsf@alter.siamese.dyndns.org>
On Thu, Dec 1, 2011 at 1:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> What I'm thinking is whether it's possible to decouple two sha-1 roles
>> in git, as object identifier and digest, separately.
>
> Why it would be a good thing? If you have a collided identifier, somebody
> has to choose which blob a particular tree wants to have at the path, and
> because the tree would not record anything but the identifier, you cannot.
Accidental collision likelihood is small enough we don't have to care about.
>> ...
>> The day sha-1 is broken, a project can generate new digests from its
>> old good repo and enforce developers to use new digests for
>> verification instead of sha-1. sha-1 is still used by git as
>> identifier after that day.
>
> And an old blob that is identified with a SHA-1 now has a new blob that
> has different contents but happens to have the same SHA-1. How does Git
> decide which blob to use when a particular object is named by the SHA-1?
Again, I assume the likelihood that a content happens to have the same
sha-1 with another one is too low to care about. If they are, it's
must be an attack. We do not allow malicious objects to enter in the
first place using other digests. Once objects are in, they are safe to
use.
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC 1/2] pull: pass the --no-ff-only flag through to merge, not fetch
From: Junio C Hamano @ 2011-12-01 4:58 UTC (permalink / raw)
To: Samuel Bronson; +Cc: git
In-Reply-To: <1322703537-3914-1-git-send-email-naesten@gmail.com>
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.
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.
I dunno.
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Jeff King @ 2011-12-01 5:26 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git, gitster, pclouds, spearce, torvalds
In-Reply-To: <1322700075.1710.157.camel@yos>
On Wed, Nov 30, 2011 at 04:41:15PM -0800, Bill Zaumen wrote:
> Aside from that, suppose the attacker does what you suggests (providing
> a valid CRC so that git commands like verify-pack don't have an error
> to detect). You can't tell that something is wrong, but Linus can -
> the next time he does a fetch. If he fetches, the server sends
> some SHA-1 hashes and the client responds with 'have' or 'want' in a
> reply. If the client wants it, the client doesn't have a CRC, if the
> client sends 'have', the CRCs are available so those get sent. The
> server then checks, notices a mismatch (probably in the CRC of the CRCs
> of all the blobs in the commit's tree), and generates an error.
OK. I thought your claim was that this would help detect
collision-related forgeries in the chain of hashes while verifying a
signed tag. But your claim is only that your scheme gives people who
already have the objects an additional chance to notice discrepencies in
what the server is serving and what they have. And then they can notify
other people of the problem in an out-of-band way (i.e., telling
kernel.org admins that the system is hacked, or telling users not to
fetch from there).
Cryptographically speaking, I think that claim is sound, and you can
certainly construct attack scenarios where this detection would help.
However, quantifying the effectiveness is difficult. What is the
likelihood of a malicious collided-object replacement being detected
without your scheme? What is it with it?
There are many questions that factor into guessing the latter.
How often does Linus fetch from his own kernel.org repository? He would
usually push, I would think. Even if he does fetch, he wouldn't be
getting the old objects that he already has. I guess this is the reason
for your digest-of-digests for each commit object sent? But what about
objects that are no longer in current commits, but are in older ones?
E.g., v1.0 of foo.c has sha1 X, and an attacker finds a collision and
replaces it. Meanwhile, the tip of development now has replaced foo.c
with X'. When Linus talks to the server, git will never care about X (it
is neither being transmitted, nor is part of a commit that is being
transmitted). But people may still be cloning and using the v1.0 tag,
assuming it is valid.
What about the server being more clever about hiding the replacement
object? E.g., instead of just breaking into kernel.org and inserting a
replacement object, the attacker runs a malicious git-daemon that
returns the bogus object to cloners, but the real object to fetchers.
Thus there is nothing for Linus to detect, but new cloners get the
malicious object. Or you could give the bogus object to people who are
getting the object for the first time (since they presumably have no
crc for that object), but otherwise use the real object.
You could get around this deception by pretending to be a "victim";
i.e., cloning fresh and seeing what the server gives you, comparing it
to your known-good repository. Which is similar to what you suggest
here:
> It's also possible to write some additional commands to (for example)
> fetch the SHA-1 hashes and CRCs from all remote repositories you use
> and compare these to make sure they are all consistent, something that
> can be run ocassionally.
But we can already do that. Assume you have an existing repo "foo". To
verify the copy at git://example.com/foo.git, do a fresh clone to
"bar", and then compare the objects in "foo" to "bar", either byte-wise
or by digest.
> That result for birthday attack assumes the goal is to find two files
> that will have the same SHA-1 value (or SHA-1 + CRC). The case I was
> talking about (apologies if I did not state this clearly) is that you
> have an existing object and an existing CRC and you want to generate
> a second object with the same SHA-1 and same CRC as the first. A
> birthday attack doesn't work so well in that case - the number of tries
> is much higher than half the number of bits in the digest.
Yes. This is called a "pre-image" attack (to be more specific, it is a
"second pre-image attack", since you have the original object). And
AFAIK, it's not feasible against SHA-1, nor will it be in the near
future (even MD5, which is considered totally broken, does not have
feasible pre-image attacks).
> http://en.wikipedia.org/wiki/Birthday_attack#Digital_signature_susceptibility
> has a discussion regarding digital signatures. The trick is for a
> person to create a large number of variations of a "fair" and "unfair"
> contract, and use a birthday attack to find a pair that have the same
> hash. The variations are typically inconsequential changes (extra
> spacing, commas, etc.)
Right. This is the classic birthday attack. I don't keep up with the
state of the art in collision attacks these days, but I think in
practice they are usually executed by adding arbitrary binary garbage
into a "hidden" spot in a file. Which makes it much harder to execute
against text files like source code (as opposed to, say, a binary
firmware blob). IIRC, the practical MD5 attacks involved postscript
documents (with non-printing garbage sections that printers would
ignore).
> In the case I was discussing, a developer creates some code, commits
> it and pushes it to a shared repository - the developer is not given
> code by the attacker. The attacker can, however, see the code by
> fetching it. An attack then consists of generating a collision,
> change the object in the attacker's local repository, and then push
> the original developer's commit (with the modified object) to another
> shared repository before someone else puts the correct objects into
> that repository. A birthday attack does not work in this case.
Yeah, that is simply not feasible, and is not likely to become so
anytime soon.
> There one issue that this suggests however - it is not clear if the
> 2^57 number given for the best SHA-1 attacks were attempts to generate
> a new file with the same SHA-1 hash as an existing file or a pair of
> files that have the same SHA-1 hash. If it is the latter, then an
> attack is significantly harder than I assumed as a worst case, but
> still possibly much, much better than brute force.
The 2^57 number is for a collision of two new objects, not for a
pre-image attack. AFAIK, there are currently no pre-image attacks on
SHA-1 at all.
I don't think there's a need to response individually to the points in
the rest of your email; they're all based on the assumption that the
attacker is replacing a known-good written-by-Linus commit with one
found in a pre-image attack.
-Peff
^ permalink raw reply
* Re: [HELP] Adding git awareness to the darning patch management system.
From: Jeff King @ 2011-12-01 6:27 UTC (permalink / raw)
To: Peter Williams; +Cc: git
In-Reply-To: <4ED6D0DB.3060800@users.sourceforge.net>
On Thu, Dec 01, 2011 at 10:56:59AM +1000, Peter Williams wrote:
> >I'm not exactly sure what this means.
>
> If you look at the screenshots at sourceforge (which were produced on
> top of a Mercurial repo) you'll notice that file names in the left
> most tree have letters in front of them and appear in different
> foreground colours. These letters are the same as those returned by
> Mercurial's status command and, hence, give a Mercurial user an easy
> to understand snapshot of the status of the files in the playground.
> The colour coding is (relatively) arbitrary (and chosen by me) and is
> intended to make it easier to detect the different file statuses.
>
> My main problem is that I can't find a git file status command (and
> there are a lot of them to choose from) that gives a snapshot of the
> statuses of all files in a directory (including those not tracked or
> ignored).
Thanks, that helps. You probably just want to use "git status
--porcelain", which will show you the state of file modification with
respect to the index and the prior commit, as well as any untracked
files. See the "porcelain format" section in "git help status".
Note that "git status" will not print files which are not modified. You
may want to also run "git ls-files" to get the full listing of files,
including unmodified ones.
> A secondary problem is that, if I could cobble together statuses from
> various commands, mapping git statuses to the Mercurial ones for
> display would not be a good solution as they would not necessarily
> make sense to a git user. (It's fairly clear to me from my inability
> to make sense of git's CLI that git users think differently to me, a
> Mercurial user, and it's unlikely that I can, without help, make a
> file tree display that makes sense to a git user.)
I'm hoping that "git status --porcelain" will give you a fairly close
mapping of the basic "what happened to this file" concept, based on what
I see in the second screenshot you mentioned.
The trickiest thing is the index, which represents an in-between state
that is not usually exposed by other version control systems. If your
tool does not make use of the index, then it probably makes sense to
just consider a path as modified if it has modifications staged in the
index or in the working tree, which maps to other VCS's idea of
"modified" (because for them, marking something as to-be-committed and
commiting it are part of the same step).
> >For this, you probably want "git diff-files --name-only", which will
> >show files with differences in the working tree. Keep in mind that git
> >has an "index" or "staging area", which means that you have three states
> >of content for a given path:
> >
> > 1. the state of the prior commit (i.e., HEAD)
> >
> > 2. the state that is marked to be committed when "git commit" is run
> > (i.e., the index)
> >
> > 3. the state in the working tree
>
> This is a prime example of the different mindset of the git user to
> the hg user.
You don't have to use those features, of course. It's just that
something like "git status" is going to report on the differences
between those states, so as a tool writer you need to know they are
there (and as I said above, you are free to simplify if it fits into the
mental model of your tool).
> >You can compare the first two with "git diff-index", and the latter two
> >with "git diff-files". You can also use "git status --porcelain" to get
> >a machine-readable output that shows how the three states match up, with
> >one line per file.
>
> This is an example of why I'm confused. There are too many ways to
> do (similar) things and it's hard to know which to use.
Git is made of little building blocks. The original way to see the
differences between the index and the working tree was via diff-files.
But then people build bigger building blocks out of the smaller ones.
"git status" is really just a shorthand for:
git diff-index HEAD &&
git diff-files &&
git ls-files -o
and is in fact implemented using those building blocks (originally as a
shell script, though these days it is written in C). So you can choose
either and get the same information. Choosing a higher-level building
block may save you some work, if the abstraction matches what you want.
Otherwise, you can compose what you want from the lower levels.
I know it sometimes leads to an overwhelming number of commands, and I'm
not trying to excuse git's tendency to confuse people. I'm just hoping
to unconfuse you in this particular situation.
In your case, I think "status" is the most convenient level of
abstraction for you, because you are interesting in looking at
differences to both the index and HEAD (i.e., the prior commit). But if
you find as you implement that want more flexibility, you can switch to
using the lower-level commands yourself.
> Maybe an example of why I think the feature is useful might help.
> Say that you start editing a file and then decide that you want to
> put this change into a patch rather than committing it. If you were
> using quilt you would have to do this manually by any of a number or
> ways such as:
>
> $ <git diff command> file > temp.patch
> $ <git revert command> file
> $ quilt new one.patch
> $ quilt add file
> $ patch -p1 file < temp.patch
> $ rm temp.patch
>
> In darning, you just do:
>
> $ darn new one.patch
> $ darn add --absorb file
Sure. We have stgit and topgit, which do similar patch management things
on top of git. I don't personally user either, though, so I don't have
much to say on how they compare to darning, or whether it is worth
looking at their implementations.
> The interface to the SCM to support this is two functions:
>
> 1: get_files_with_uncommitted_changes() which called with no
> arguments returns a list of the paths of all files with uncommitted
> changes or when given a list of file paths (the more common case)
> returns the subset of that list which have uncommitted changes; and
"status" will do this for you, modulo the simplification of the concept
of the index, as we discussed above.
> 2. copy_clean_version_to(filepath, target_path) which makes a copy of
> the file as recorded in the prior commit and places it at the
> target_path (usually where darning stores the "original" for
> reference when creating diffs).
You probably want:
git cat-file blob HEAD:filepath >target_path
-Peff
^ 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
* 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 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
* 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: 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
* 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
* 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: [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
* 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: 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
* 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: [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
* 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
* [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
* [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
* 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
* 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: 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
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