* Re: shared permissions on COMMIT_EDITMSG
From: demerphq @ 2010-01-28 17:57 UTC (permalink / raw)
To: William Pursell; +Cc: Ilari Liusvaara, git
In-Reply-To: <4B61C371.4050903@gmail.com>
2010/1/28 William Pursell <bill.pursell@gmail.com>:
> Ilari Liusvaara wrote:
>> On Wed, Jan 27, 2010 at 11:19:22PM -1000, William Pursell wrote:
>>> With git-init --shared=0660 and a umask of 022,
>>> the first commit to the repository creates
>>> the file COMMIT_EDITMSG with mode 0644
>>> instead of 0660. I believe this is incorrect
>>> behavior. Simple fix:
>>
>> COMMIT_EDITMSG is related to committing, committing needs
>> working copy, and shared working copies don't work all too
>> well (and Git can't do anything about that because all kinds
>> of stuff edits the files there, not just Git).
>>
>> Shared repository settings are meant to override umasks
>> for files in actual repository itself.
>
> For simple work flows (eg recording linear history
> of config files), sharing a working directory
> works okay except for COMMIT_EDITMSG. Since
> COMMIT_EDITMSG is in the git repository and only
> written by git, it makes sense for core.sharedrepository
> to be honored.
I agree. And personally ive used shared working directories quite a
bit without issue. Thanks be to git --interactive.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Questions about branches in git
From: Mike Linck @ 2010-01-28 18:44 UTC (permalink / raw)
To: git
Hi, my company switched to git a few months ago because the way it
handles submodules seems safer to us than our previous scm tool and
because our ruby developers wanted to take advantage of the community
on github. However, I'm having some problems getting git's
representations of branches to show me what change sets they contain.
It seems that after a topic or bug branch is merged back into its
parent, especially if it was fast forwarded, it becomes hard to
determine what changes were made in it, to resolve the problem that it
was created to address. This is fairly important to me since I need
to be able to backport fixes to older revisions on occasion, and to
perform development on multiple releases for multiple platforms in
parallel, so it seems really handy for a branch to show us just the
changes that were made in it, between the time it was spawned from its
parent and the time the parent accepted its changes.
I've looked through as much documentation as I can find about git show
and git log, and I've played around with git rebase to try to apply
changes to multiple places, but I have not been able to find a way to
display the commits relevant to a particular bug/topic branch.
Rebasing from a branch that has already had the changeset merged back
in, to another branch, seems to actually wipe out the contents of the
branch completely.
I understand that there are mechanism kind of available to address
this problem. If we (all developers in my company) remember always to
rebase -i before they merge their topic branches back in, then it
could be squashed making it easier to identify and cherry pick onto
other branches, or *if* we always remember to rebase before we merge
and then create a patch set and store that on the topic branch, we
could kind of organize our change sets that way. But it seems that it
should be easier than that, shouldn't it? If I look at the git log
for a branch, I really feel that I should see some distinction between
that changes that were originally made on a branch, and the ones that
were inherited from some other branch or merged in from some other
branch. Simply because mistakes get made and if you we don't realize
that a fix may need to be applied to some older revision when we first
develop it, it seems that this could really cost a lot of time and
money to try to identify the individual commits that were useful in
addressing the problem.
What am I missing here?
Any help is appreciated.
Thank you,
Michael Linck
^ permalink raw reply
* Re: [PATCH 3/3] reject @{-1} not at beginning of object name
From: Junio C Hamano @ 2010-01-28 20:02 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git, Johannes Schindelin
In-Reply-To: <20100128095643.GC14253@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Something like foo@{-1} is nonsensical, as the @{-N} syntax
> is reserved for "the Nth last branch", and is not an actual
> reflog selector. We should not feed such nonsense to
> approxidate at all.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> We didn't discuss this one, but I came across it while trying to be
> complete in testing the combinations. Right now "foo@{-1}" is
> interpreted as a reflog entry at approxidate "-1". Approxidate doesn't
> signal an error because it thinks it has found something useful. But
> AFAIK we have declared all @{-...} to be Nth last branch, so it is
> simply a semantic error.
>
> Let me know if that is not the case (that is, if it was intentional to
> leave foo@{-1} as the reflog at date "-1" because it has some meaning
> that I am missing) and we can drop this patch.
I think the patch is fine as is.
We might want to use @{-some string that has non digit} for other purposes
and it may be a safer change to tweak the "do we only have digits" check
in the post-context to detect and reject only @{-<all digits>}.
But what I am puzzled by the code structure of get_sha1_basic(), which
looks like this:
get_sha1_basic() {
- do we have @{...} at end? If so, and if it is not a magic like
@{u}, set "len" (points at the end of stuff that should name a ref)
and "reflog_len" (the length of the reflog time/num specifier that
is applied to that ref).
- did we find @{...} in the above check, and is it at the beginning?
Then it is not a reflog syntax, but is a N-th branch switch.
Substitute that @{...} with the real refname and retry. If it is
not @{-N}, then that @{...} reflog derefence should apply to the
current branch, so set it to real_ref and go to "reflog" part.
- if we have @{...} at the end, get the canonical name of the ref the
reflog notation is applied to.
- otherwise, get the canonical name of the ref; in this case,
there is no @{...} at the end, si this is what is eventually
returned.
- "reflog" part:
by now, real_ref holds the ref @{...} is being applied to. Read
from its reflog.
}
And the place that parses @{-1} and @{u} are different, even though both
dwim_log() called by the third one and dwim_ref() called by the fourth one
call substitute_branch_name() and they are perfectly capable of resolving
@{-1} and @{u} (and even nested stuff like @{-1}@{u}@{u} with your patch).
But somehow we kept the special case code to parse @{-1} in the second
one.
Side note. I am wondering if dwim_log()'s current implementation is
even correct in the first place. When you have two "ambiguous" refs,
it appears to me that you will get a warning from dwim_ref(), but if
only one of them has a reflog associated with it, dwim_log() won't
complain. Why isn't the function be (1) dwim_ref() to find the ref
from abbreviated refname given in str; and then (2) check if the log
exists for that ref?
It might be cleaner if the logic went like this instead:
- find the last @{...} in the string that is not what i-b-n should
resolve (i.e. @{-1} and @{u}); that is @{time/num} reflog
reference. You can have at most one reflog reference and it always
has to come at the end.
- feed the remainder to (an updated) i-b-n that knows how to grok:
- @{-N} is nth-priour checkout; it has to come at the beginning and
you can have at most one. If you find it, substitute it with the
real branch name and continue. (e.g. @{-1}@{u} becomes master@{u})
- does it begin with @{...}? If not, the part before @{...} is the
name of the ref (e.g. "next" in "next@{u}@{u}") the later magic
sequence (e.g. "@{u}@{u}") is applied to; otherwise apply the
magic to what HEAD points at (e.g. "@{u}" applies @{u} to the
current branch). Remember that ref and strip it away from the
input.
- while we see sequence of @{...}, apply the magic to the ref
repeatedly (e.g. "next@{u}@{u}" has remembered "refs/heads/next" in
the previous step, and @{u} is applied to produce "master" if next
follows master, and then applying @{u} to that result will tell us
that it follows "refs/remotes/origin/master").
- now we have what ref the caller was talking about with the beginning
part of the input (i.e. without "@{time/num}" at the end). If we
had @{time/num} in the original input, open the reflog and find an
appropriate entry in it. Otherwise what we received from (the
updated) i-b-n is what we found. Find out what object the ref
points at.
But that is a kind of code churn that may not be worth doing. I dunno.
^ permalink raw reply
* Re: Questions about branches in git
From: Michael Witten @ 2010-01-28 20:03 UTC (permalink / raw)
To: Mike Linck; +Cc: git
In-Reply-To: <69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com>
On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
<mgl@absolute-performance.com> wrote:
> ...
> It seems that after a topic or bug branch is merged back into its
> parent, especially if it was fast forwarded, it becomes hard to
> determine what changes were made in it, to resolve the problem that it
> was created to address.
> ...
> I understand that there are mechanism kind of available to address
> this problem. If we (all developers in my company) remember always to
> rebase -i before they merge their topic branches back in, then it
> could be squashed making it easier to identify and cherry pick onto
> other branches...
For now, you should probably rely on graphical tools like gitk in
order to visualize the various branches. There's also `git log
--graph'. You could also just keep your branches around for reference
and use `git merge-base' as necessary.
However, I've been thinking for a while that it would be useful to
have übercommits (they don't exist) that are treated like single
commits but that actually encapsulate multiple continguous commits.
For your case, you could tell git to make merges by creating such
übercommits, which would then be easily identified, referenced, and
manipulated for your backporting purposes; such übercommits would
encapsulate the relevant commits.
These übercommits would also allow developers to make a string of
commits that by themselves break things but together formulate a
complete solution; because the übercommits encapsulate the breakage,
bisection would still be simple (no fear of dealing with broken
commits), but the small manageable commits would still be available
for references and manipulation.
Perhaps trees could be reappropriated for the implementation of übercommits.
Sincerely,
Michael Witten
^ permalink raw reply
* Re: Questions about branches in git
From: Michael Witten @ 2010-01-28 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com>
On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
> However, I've been thinking for a while that it would be useful to
> have übercommits (they don't exist) that are treated like single
> commits but that actually encapsulate multiple continguous commits.
In fact, the commit message body is already being used to create
unofficial übercommits. Consider a common merge commit from a
clone of Linus's Linux repo:
commit e80b1359858df17b0034bdf7d1b6f3e0d5b97257
Merge: 341031c b27d515
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Jan 21 08:50:04 2010 -0800
Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf: x86: Add support for the ANY bit
perf: Change the is_software_event() definition
perf: Honour event state for aux stream data
perf: Fix perf_event_do_pending() fallback callsite
perf kmem: Print usage help for unknown commands
perf kmem: Increase "Hit" column length
hw-breakpoints, perf: Fix broken mmiotrace due to dr6 by reference change
perf timechart: Use tid not pid for COMM change
It seems like this kind of useful information should be a more
integral part of the metadata.
Indeed, it seems like commit messages are often used for metadata
that git perhaps *should* handle natively, like sign-offs and
multiple Authors, etc.
Of course, I'm betting that git doesn't handle such things
officially because it would require more general data structures
(especially for variable numbers of Authors) and thus slower
algorithms.
Sincerely,
Michael Witten
^ permalink raw reply
* Re: show/diff --check clarification needed
From: Junio C Hamano @ 2010-01-28 20:25 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <d26982ce92a061ee24d04aba6e314fa4.squirrel@intranet.linagora.com>
"Yann Dirson" <ydirson@altern.org> writes:
> Unless I missed something, I suggest the following plan:
>
> - document in maint that --check only takes worktree into account when
> looking for .gitattributes, and more globally add a note to the
> gitattributes manpage to explicitely say that too.
It is not limited to "diff --check". The current implementation reads
attributes only from the checked out work tree and/or from the index,
depending on the direction of operation (e.g. checking out files to work
tree reads from the index, I think). The same issue would affect "git
archive" when generating a tarball from an older revision.
The exception is $GIT_DIR/info/gitattributes, and for your particular
purpose, I think it is the right one to use, because the entries in that
file will apply regardless of which version you are examining patches
from.
> - add a global flag to allow something like
> "git --attributes-tree=<treeish> <command>"
I am not sure if this is what we really want. It seems to me that it
would make more sense to read from a relevant tree that the <command>
is operating on, if we are to enhance the attributes implementation. If
that <treeish> is a fixed one, it is not much better than having necessary
entries in your $GIT_DIR/info/gitattributes file.
> - adjust defaults to agreed-upon values
> - add any config entries that would be meaningful
Sorry, I have no idea what you mean by these two points.
Thanks.
^ permalink raw reply
* Re: [PATCH] grep: expose "status-only" feature via -q
From: Junio C Hamano @ 2010-01-28 20:27 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <4B61BC02.3070408@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> On 01/25/2010 03:37 PM, Junio C Hamano wrote:
>> @@ -505,6 +512,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
>> { OPTION_CALLBACK, ')', NULL,&opt, NULL, "",
>> PARSE_OPT_NOARG | PARSE_OPT_NONEG | PARSE_OPT_NODASH,
>> close_callback },
>> + OPT_BOOLEAN('q', "quick",&opt.status_only,
>> + "indicate hit with exit status without output"),
>>
>
> Why isn't this --quiet just like grep?
Because I wasn't careful enough. Thanks; will fix.
^ permalink raw reply
* Re: Questions about branches in git
From: Michael Witten @ 2010-01-28 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com>
On Thu, Jan 28, 2010 at 2:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
> These übercommits would also allow developers to make a string of
> commits that by themselves break things but together formulate a
> complete solution; because the übercommits encapsulate the breakage,
> bisection would still be simple (no fear of dealing with broken
> commits), but the small manageable commits would still be available
As a corollary to this, developers can maintain patch integrity.
Quite often, I've sent a patch off to some project only to have
the maintainer `tweak' the result before making a commit. However,
I frankly don't want my name attached to someone else's work,
because I may disagree with what has been done.
Were übercommits available, the maintainer could commit my original
work and then make a new `tweak' commit and then bundle the 2 together
as an übercommit in order to encapsulate this series of events.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #05; Sat, 16)
From: Avery Pennarun @ 2010-01-28 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd417udpi.fsf@alter.siamese.dyndns.org>
On Mon, Jan 18, 2010 at 1:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> [Stalled]
>>
>> * ap/merge-backend-opts (2008-07-18) 6 commits
>> - Document that merge strategies can now take their own options
>> - Extend merge-subtree tests to test -Xsubtree=dir.
>> - Make "subtree" part more orthogonal to the rest of merge-recursive.
>> - Teach git-pull to pass -X<option> to git-merge
>> - git merge -X<option>
>> - git-merge-file --ours, --theirs
>>
>> "git pull" patch needs sq-then-eval fix to protect it from $IFS
>> but otherwise seemed good.
>
> Generally I hate to step in to fix up other's series, especially when I
> know that the party responsible for issues is capable enough. As the
> pre-release feature freeze gets closer, however, I sometimes find myself
> doing so, and (I repeat) I hate it.
Sorry about that. I asked at the time whether you thought I should
submit a patch or whether you were planning to do it, and didn't get
an answer. And then when you wrote the above, I was away on vacation.
I see it's now been merged into master, but in case you care... it
looks ok to me :)
Have fun,
Avery
^ permalink raw reply
* Re: Questions about branches in git
From: Mike Linck @ 2010-01-28 21:17 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com>
On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
> <mgl@absolute-performance.com> wrote:
>> ...
>> It seems that after a topic or bug branch is merged back into its
>> parent, especially if it was fast forwarded, it becomes hard to
>> determine what changes were made in it, to resolve the problem that it
>> was created to address.
>> ...
>> I understand that there are mechanism kind of available to address
>> this problem. If we (all developers in my company) remember always to
>> rebase -i before they merge their topic branches back in, then it
>> could be squashed making it easier to identify and cherry pick onto
>> other branches...
>
> For now, you should probably rely on graphical tools like gitk in
> order to visualize the various branches. There's also `git log
Well, even gitk can't show me the information I'm looking for if the
parent branch ended up fast-forwarding to include the changes made in
the topic branch. As far as I can tell there is *no way* to tell what
changes were made in a particular branch after a fast-forward has
taken place, which seems to make it hard to organize fixes for
specific topics/bugs/tickets.
> --graph'. You could also just keep your branches around for reference
> and use `git merge-base' as necessary.
>
Yeah, what concerns me is that there seems to be no point in keeping
your branches around "for reference" because even when you're looking
at them you can't tell what changes were made in them after they were
spawned, unless they haven't been merged into another branch yet. So
it seems that a branch is only useful for merging once and unless the
branch was squashed in the process of mergin, good luck identifying
your change set for a particular topic.
I don't know if an uebercommit is necessary. But it would help seem
like it would help if a branch knew about it's spawn point from its
parent, and if you could use that to get git log to only show you the
commits made to a branch after it was spawned. And if there were
forms of operations like merge, or rebase that could act intelligently
based on that information like "merge this branch into that branch,
and by this branch I don't mean anything from this branch's parent
branch" so that a fix that was developed on edge or master could be
safely merged into an old branch without importing every other change
on edge or master, and also the other way around.
I just looked at merge-base. It doesn't seem to address the problem.
I grabbed an old topic branch from our repo which I knew was created
from master and at some point merged back into master via
fast-forward. I checked it out, I called "git merge base topic-id
master", hoping that it would "output a commit which is reachable from
both A and B through the parent relationship." Instead it seems to
have modified the topic branch by fast forwarding it to the include
all the changes up to the tip of master. Clearly not what I'm looking
for.
Michael Linck
^ permalink raw reply
* [PATCH] git gui: Quote git path properly when starting another gui in a submodule
From: Jens Lehmann @ 2010-01-28 21:20 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: Git Mailing List, Heiko Voigt
In-Reply-To: <20100128025647.GB8166@spearce.org>
In do_git_gui() the path of the git executable has to be put into a list,
otherwise calling it will fail when when spaces are present in its path.
Reported-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 28.01.2010 03:56, schrieb Shawn O. Pearce:
> Jens Lehmann (2):
> git-gui: Use git diff --submodule when available
> git-gui: Add a special diff popup menu for submodules
Today Heiko reported me this bug I introduced with the second patch.
Sorry for the hassle.
git-gui/git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index a64191d..840f45c 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -2000,7 +2000,7 @@ proc do_git_gui {} {
# -- Always start git gui through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
- set exe [_which git]
+ set exe [list [_which git]]
if {$exe eq {}} {
error_popup [mc "Couldn't find git gui in PATH"]
} else {
--
1.7.0.rc0.163.g808df.dirty
^ permalink raw reply related
* Re: Questions about branches in git
From: Jens Lehmann @ 2010-01-28 21:29 UTC (permalink / raw)
To: Mike Linck; +Cc: Michael Witten, git
In-Reply-To: <69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com>
Am 28.01.2010 22:17, schrieb Mike Linck:
> Well, even gitk can't show me the information I'm looking for if the
> parent branch ended up fast-forwarding to include the changes made in
> the topic branch. As far as I can tell there is *no way* to tell what
> changes were made in a particular branch after a fast-forward has
> taken place, which seems to make it hard to organize fixes for
> specific topics/bugs/tickets.
You could disable fast forward merges using the --no-ff option. Then
git will always create a merge commit even if it could have done a
fast forward. This can be enabled permanently for a branch with
'git config branch.master.mergeoptions "--no-ff"'. We use that at my
dayjob to preserve the branches after merging.
^ permalink raw reply
* Re: show/diff --check clarification needed
From: Yann Dirson @ 2010-01-28 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxzykmdp.fsf@alter.siamese.dyndns.org>
On Thu, Jan 28, 2010 at 12:25:22PM -0800, Junio C Hamano wrote:
> "Yann Dirson" <ydirson@altern.org> writes:
>
> > Unless I missed something, I suggest the following plan:
> >
> > - document in maint that --check only takes worktree into account when
> > looking for .gitattributes, and more globally add a note to the
> > gitattributes manpage to explicitely say that too.
>
> It is not limited to "diff --check". The current implementation reads
> attributes only from the checked out work tree and/or from the index,
> depending on the direction of operation (e.g. checking out files to work
> tree reads from the index, I think). The same issue would affect "git
> archive" when generating a tarball from an older revision.
>
> The exception is $GIT_DIR/info/gitattributes, and for your particular
> purpose, I think it is the right one to use, because the entries in that
> file will apply regardless of which version you are examining patches
> from.
Well, it would have serious disavantages:
- if used alone, info/attributes is not obtained as part of the fetch (so
needs additional logic to deploy into dev's workspaces)
- if used together with .gitattribute files, would need to be synchronized
on pull, but then:
- would also need a policy to tell from which head to update
- mapping from a set of .gitattributes distributed in the tree is possibly
not trivial (I have not succeeded to affect files in a specific subdir
from the toplevel .gitattributes, and the manpage does not seem to mention
that info/gitattributes allows more flexibility in this respect)
> > - add a global flag to allow something like
> > "git --attributes-tree=<treeish> <command>"
>
> I am not sure if this is what we really want. It seems to me that it
> would make more sense to read from a relevant tree that the <command>
> is operating on, if we are to enhance the attributes implementation. If
> that <treeish> is a fixed one, it is not much better than having necessary
> entries in your $GIT_DIR/info/gitattributes file.
The idea with this flag is not to have <treeish> fixed, but more for use by
other commands/porcelain, who would make themselves the decision of which
treeish to take attributes from.
> > - adjust defaults to agreed-upon values
> > - add any config entries that would be meaningful
>
> Sorry, I have no idea what you mean by these two points.
That was partly intentionally vague, partly to blame on me being tired :)
- once the --attributes-tree feature would be in place, various commands like
diff-tree and show will be able to decide what makes more sense as a default
for the requested operation. Depending on the command and the particular
invocation, the default to use may not always be obvious, so I expect the
general default will be kept to the working tree.
- as ususal, people may want to use different settings than the default for
some commands, so support for overriding them via the config mechanism should
be put in place.
Anyway, how we specify the rule of which treeish to use for this will not be
possible with simply a treeish. That will probably have to use keywords
that would be meaningful in the context of the operation.
I would expect that all operations would be able to be told "worktree", "index",
and to be given any treeish - this in itself is a problem, I don't think we
already have a "treeish" syntax for worktree and index.
Additionally, "show" applied to a treeish would allow to tell to use the treeish
it is showing (or one of its parents); similarly when applied to "<committish>:<path>"
syntax; "diff-tree" would allow either the positive or negative reference; etc.
All that would also require a special syntax, so it can be specified as a
generally-useful value in the config file.
^ permalink raw reply
* Re: Questions about branches in git
From: Mike Linck @ 2010-01-28 21:38 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Michael Witten, git
In-Reply-To: <4B6201BC.9030800@web.de>
On Thu, Jan 28, 2010 at 2:29 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 28.01.2010 22:17, schrieb Mike Linck:
>> Well, even gitk can't show me the information I'm looking for if the
>> parent branch ended up fast-forwarding to include the changes made in
>> the topic branch. As far as I can tell there is *no way* to tell what
>> changes were made in a particular branch after a fast-forward has
>> taken place, which seems to make it hard to organize fixes for
>> specific topics/bugs/tickets.
>
> You could disable fast forward merges using the --no-ff option. Then
> git will always create a merge commit even if it could have done a
> fast forward. This can be enabled permanently for a branch with
> 'git config branch.master.mergeoptions "--no-ff"'. We use that at my
> dayjob to preserve the branches after merging.
>
OK, so what I'm getting is that if a developer forgot to disable
fast-forward when they created a topic branch, and if the parent
branch has been fast forwarded to include it, then you might as well
just throw away the topic branch, is that correct?
Could anyone point me to a good book that actually describes the style
of code management that git was intended to support? Because I'm
finding this a bit baffling, to be honest. I thought it was intended
to make the developers' side of code management easier to do, but it
seems to me that they have to think a lot harder about what they're
trying to accomplish, at least in this sort of case. I'm not trying
to be rude, but I just feel that if I want to keep working with this
tool, I have to rethink how the code is organized in a pretty
fundamental way and I'd like to get as comprehensive of a guide as
possible from someone who has adopted their tactics to it.
Thanks
Michael Linck
^ permalink raw reply
* Re: [PATCHv4 2/2] filter-branch: Add tests for submodules in tree-filter
From: Junio C Hamano @ 2010-01-28 21:57 UTC (permalink / raw)
To: Michal Sojka; +Cc: git, j.sixt, Johannes.Schindelin, gitster
In-Reply-To: <1264669727-9977-2-git-send-email-sojkam1@fel.cvut.cz>
Michal Sojka <sojkam1@fel.cvut.cz> writes:
> @@ -306,4 +306,43 @@ test_expect_success '--remap-to-ancestor with filename filters' '
> test $orig_invariant = $(git rev-parse invariant)
> '
>
> +test_expect_success 'setup submodule' '
> + rm -rf * .*
Yikes. Please don't do this.
If you cannot structure your tests following what has already been done by
the previous tests, at least name the things that you want to remove a bit
more explicitly to avoid mistakes. The loosest form that is reasonable
would probably be (to catch a, actual, backup-refs, ... and .git):
rm -fr ?* .?* &&
but it would be preferable to be even more explicit "rm -fr ?* .git".
Also make sure you don't break the chain of "&&" unnecessarily.
> + git init &&
> + test_commit file &&
> + mkdir submod &&
> + submodurl="$PWD/submod"
> + ( cd submod &&
> + git init &&
> + test_commit file-in-submod ) &&
> + git submodule add "$submodurl"
"&&"?
^ permalink raw reply
* Re: Questions about branches in git
From: Nicolas Pitre @ 2010-01-28 22:04 UTC (permalink / raw)
To: Mike Linck; +Cc: Michael Witten, git
In-Reply-To: <69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com>
On Thu, 28 Jan 2010, Mike Linck wrote:
> Well, even gitk can't show me the information I'm looking for if the
> parent branch ended up fast-forwarding to include the changes made in
> the topic branch. As far as I can tell there is *no way* to tell what
> changes were made in a particular branch after a fast-forward has
> taken place, which seems to make it hard to organize fixes for
> specific topics/bugs/tickets.
You should consider using tags in conjunction with your bugs/tickets
system. The fork point for a bug fix may be tagged, as well as the last
commit representing the bugfix completion (not the merge point though).
This way you can always retrieve the exact set of commits forming up
that bugfix, regardless if it was merged back into the main branch with
a fast forward or not.
Nicolas
^ permalink raw reply
* Re: Questions about branches in git
From: David Aguilar @ 2010-01-28 22:14 UTC (permalink / raw)
To: Michael Witten; +Cc: Mike Linck, git, Nicolas Pitre
In-Reply-To: <alpine.LFD.2.00.1001281656440.1681@xanadu.home>
On Thu, Jan 28, 2010 at 05:04:36PM -0500, Nicolas Pitre wrote:
> On Thu, 28 Jan 2010, Mike Linck wrote:
>
> > Well, even gitk can't show me the information I'm looking for if the
> > parent branch ended up fast-forwarding to include the changes made in
> > the topic branch. As far as I can tell there is *no way* to tell what
> > changes were made in a particular branch after a fast-forward has
> > taken place, which seems to make it hard to organize fixes for
> > specific topics/bugs/tickets.
>
> You should consider using tags in conjunction with your bugs/tickets
> system. The fork point for a bug fix may be tagged, as well as the last
> commit representing the bugfix completion (not the merge point though).
> This way you can always retrieve the exact set of commits forming up
> that bugfix, regardless if it was merged back into the main branch with
> a fast forward or not.
>
>
> Nicolas
Tags, combined with --no-ff, should help you out a bit.
If you're worried about devs forgetting to configure the no-ff
then you might be able to help them out if you have any control
over /etc/gitconfig on their systems. That gives you a
standard, global way to set defaults.
This table gives a great summary of 'git log' commands for
inspecting branches.
http://book.git-scm.com/3_reviewing_history_-_git_log.html
As far as "what's the way to do branches right in git" then
there is no "one single way" because git is a framework upon
which you can build your ideal workflow. That said, there are
some very good examples to follow. For example, there is much
that can be learned by studying how git.git's branches are
managed.
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
This webcast covers a few more workflows and is a very good
crash course:
http://www.gitcasts.com/posts/railsconf-git-talk
--
David
^ permalink raw reply
* Re: Questions about branches in git
From: Michael Witten @ 2010-01-28 22:18 UTC (permalink / raw)
To: Mike Linck; +Cc: git
In-Reply-To: <69b754db1001281317o69f8c3f9y412a8524407bacbf@mail.gmail.com>
On Thu, Jan 28, 2010 at 3:17 PM, Mike Linck
<mgl@absolute-performance.com> wrote:
> On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
>> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
>> <mgl@absolute-performance.com> wrote:
>>> ...
>>> It seems that after a topic or bug branch is merged back into its
>>> parent, especially if it was fast forwarded, it becomes hard to
>>> determine what changes were made in it, to resolve the problem that it
>>> was created to address.
>>> ...
>>> I understand that there are mechanism kind of available to address
>>> this problem. If we (all developers in my company) remember always to
>>> rebase -i before they merge their topic branches back in, then it
>>> could be squashed making it easier to identify and cherry pick onto
>>> other branches...
>>
>> For now, you should probably rely on graphical tools like gitk in
>> order to visualize the various branches. There's also `git log
>
> Well, even gitk can't show me the information I'm looking for if the
> parent branch ended up fast-forwarding to include the changes made in
> the topic branch....
As Jens Lehmann pointed out, use something like:
git checkout master
git pull --no-ff . topic
>> --graph'. You could also just keep your branches around for reference
>> and use `git merge-base' as necessary.
>>
> ...
> it seems that a branch is only useful for merging once and unless the
> branch was squashed in the process of mergin, good luck identifying
> your change set for a particular topic.
> ...
I would think that you'd only care about the contiguous commits
between merges anyway.
> I just looked at merge-base. It doesn't seem to address the problem.
> I grabbed an old topic branch from our repo which I knew was created
> from master and at some point merged back into master via
> fast-forward. I checked it out, I called "git merge base topic-id
> master", hoping that it would "output a commit which is reachable from
> both A and B through the parent relationship." Instead it seems to
> have modified the topic branch by fast forwarding it to the include
> all the changes up to the tip of master. Clearly not what I'm looking
> for.
You incorrectly used `git merge' rather than `git merge-base'.
This is kind of off the top of my head. Try something like this:
merged_commit_0=$(git merge-base master topic-id)
merged_commit_1=$(git merge-base master ${merged_commit_0}^)
I think that should give you the range of commits between the last 2
merges (for at least simple cases). Then:
git log $merged_commit_1^..$merged_commit_0
or
gitk $merged_commit_1..$merged_commit_0
to see them.
You could, I suppose, keep looping until you find the oldest
merge-base that is still in the topic-id branch. To do so, the
following information may be of use:
http://marc.info/?l=git&m=126457707700573&w=2
Anyway, it's probably best to use Nicolas Pitre's suggestion to use
tags to mark commits yourself, but the above might be useful if you
haven't.
^ permalink raw reply
* Re: Questions about branches in git
From: Eugene Sajine @ 2010-01-28 22:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Mike Linck, Michael Witten, git
In-Reply-To: <alpine.LFD.2.00.1001281656440.1681@xanadu.home>
I agree with Nicolas here - i was also thinking about using
lightweight tags in this case. If you really, really need to port
changes to multiple branches, tags would show you exactly which
commits you should work with.
git log tag1(branched)..tag2(brnach_ready)
In addition to that i shold say that most of the time branches are
supposed to be created from the latest stable master, i.e. released
code. Each release should be tagged. So, in this case you don't need
to have to have the first tag, as you branching from a tagged commit.
As soon as you have first point, second tag may be not necessary until
you can operate with the last commit. As soon as it is not possible -
you can create lightweight tag.
On Thu, Jan 28, 2010 at 5:04 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> On Thu, 28 Jan 2010, Mike Linck wrote:
>
> > Well, even gitk can't show me the information I'm looking for if the
> > parent branch ended up fast-forwarding to include the changes made in
> > the topic branch. As far as I can tell there is *no way* to tell what
> > changes were made in a particular branch after a fast-forward has
> > taken place, which seems to make it hard to organize fixes for
> > specific topics/bugs/tickets.
>
> You should consider using tags in conjunction with your bugs/tickets
> system. The fork point for a bug fix may be tagged, as well as the last
> commit representing the bugfix completion (not the merge point though).
> This way you can always retrieve the exact set of commits forming up
> that bugfix, regardless if it was merged back into the main branch with
> a fast forward or not.
>
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Questions about branches in git
From: Mike Linck @ 2010-01-28 22:56 UTC (permalink / raw)
Cc: git
In-Reply-To: <b4087cc51001281418m3f19d765rd9aab03a339f15a4@mail.gmail.com>
On Thu, Jan 28, 2010 at 3:18 PM, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Jan 28, 2010 at 3:17 PM, Mike Linck
> <mgl@absolute-performance.com> wrote:
>> On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
>>> <mgl@absolute-performance.com> wrote:
>>>> ...
>>>> It seems that after a topic or bug branch is merged back into its
>>>> parent, especially if it was fast forwarded, it becomes hard to
>>>> determine what changes were made in it, to resolve the problem that it
>>>> was created to address.
>>>> ...
>>>> I understand that there are mechanism kind of available to address
>>>> this problem. If we (all developers in my company) remember always to
>>>> rebase -i before they merge their topic branches back in, then it
>>>> could be squashed making it easier to identify and cherry pick onto
>>>> other branches...
>>>
>>> For now, you should probably rely on graphical tools like gitk in
>>> order to visualize the various branches. There's also `git log
>>
>> Well, even gitk can't show me the information I'm looking for if the
>> parent branch ended up fast-forwarding to include the changes made in
>> the topic branch....
>
> As Jens Lehmann pointed out, use something like:
>
> git checkout master
> git pull --no-ff . topic
>
>>> --graph'. You could also just keep your branches around for reference
>>> and use `git merge-base' as necessary.
>>>
>> ...
>> it seems that a branch is only useful for merging once and unless the
>> branch was squashed in the process of mergin, good luck identifying
>> your change set for a particular topic.
>> ...
>
> I would think that you'd only care about the contiguous commits
> between merges anyway.
>
>> I just looked at merge-base. It doesn't seem to address the problem.
>> I grabbed an old topic branch from our repo which I knew was created
>> from master and at some point merged back into master via
>> fast-forward. I checked it out, I called "git merge base topic-id
>> master", hoping that it would "output a commit which is reachable from
>> both A and B through the parent relationship." Instead it seems to
>> have modified the topic branch by fast forwarding it to the include
>> all the changes up to the tip of master. Clearly not what I'm looking
>> for.
>
> You incorrectly used `git merge' rather than `git merge-base'.
>
> This is kind of off the top of my head. Try something like this:
>
> merged_commit_0=$(git merge-base master topic-id)
> merged_commit_1=$(git merge-base master ${merged_commit_0}^)
>
> I think that should give you the range of commits between the last 2
> merges (for at least simple cases). Then:
>
> git log $merged_commit_1^..$merged_commit_0
>
> or
>
> gitk $merged_commit_1..$merged_commit_0
>
> to see them.
>
> You could, I suppose, keep looping until you find the oldest
> merge-base that is still in the topic-id branch. To do so, the
> following information may be of use:
>
> http://marc.info/?l=git&m=126457707700573&w=2
>
> Anyway, it's probably best to use Nicolas Pitre's suggestion to use
> tags to mark commits yourself, but the above might be useful if you
> haven't.
>
Well, I'll be using tags more in the future and I'll look through some
more documentation about recommended workflows and see if I can work
out something that will do what we need to do.
Your example will work on non-FF branches if you make the second
merge-base use master~1 (else it just gives you the same commit sha
twice)
The tough thing to identify is the change sets that got fast-forwarded
in though. I guess I'll just go ahead and erase those branches since
they won't do any of us any good anyway and I'll read up on the work
flow, and try to avoid having the same mistakes recur.
thanks again,
mike
^ permalink raw reply
* Re: Questions about branches in git
From: Martin Langhoff @ 2010-01-28 23:00 UTC (permalink / raw)
To: Mike Linck; +Cc: git
In-Reply-To: <69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com>
On Thu, Jan 28, 2010 at 7:44 PM, Mike Linck
<mgl@absolute-performance.com> wrote:
> I've looked through as much documentation as I can find about git show
> and git log, and I've played around with git rebase to try to apply
> changes to multiple places, but I have not been able to find a way to
> display the commits relevant to a particular bug/topic branch.
I've done a similar job for quite a while, and kernel hackers need
that all the time too. If the branches merge a lot, what you need to
know is what patches are only on one side, and not on the other. Two
things to the rescue:
- the "3 dots" "..." separator. try with gitk and git log:
git log mybranch...hisbranch
git log hisbranch...mybranch
- git am (which is part of the rebase machinery) does the same as the
"..." operator, but has additional tricks to try and spot commits that
have been cherry picked. So I would often export patches with git am
just to review what' s on one side.
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Questions about branches in git
From: Michael Witten @ 2010-01-28 23:01 UTC (permalink / raw)
To: Mike Linck; +Cc: git
In-Reply-To: <69b754db1001281456k7c275550r5ffde67b254b510e@mail.gmail.com>
On Thu, Jan 28, 2010 at 4:56 PM, Mike Linck
<mgl@absolute-performance.com> wrote:
> Your example will work on non-FF branches if you make the second
> merge-base use master~1 (else it just gives you the same commit sha
> twice)
That's the point of the '^' character that I used in my example; it
wasn't a mistake.
^ permalink raw reply
* Re: Re: Questions about branches in git
From: Heiko Voigt @ 2010-01-28 23:07 UTC (permalink / raw)
To: Mike Linck; +Cc: Jens Lehmann, Michael Witten, git
In-Reply-To: <69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com>
On Thu, Jan 28, 2010 at 02:38:14PM -0700, Mike Linck wrote:
> On Thu, Jan 28, 2010 at 2:29 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> > Am 28.01.2010 22:17, schrieb Mike Linck:
> >> Well, even gitk can't show me the information I'm looking for if the
> >> parent branch ended up fast-forwarding to include the changes made in
> >> the topic branch. As far as I can tell there is *no way* to tell what
> >> changes were made in a particular branch after a fast-forward has
> >> taken place, which seems to make it hard to organize fixes for
> >> specific topics/bugs/tickets.
> >
> > You could disable fast forward merges using the --no-ff option. Then
> > git will always create a merge commit even if it could have done a
> > fast forward. This can be enabled permanently for a branch with
> > 'git config branch.master.mergeoptions "--no-ff"'. We use that at my
> > dayjob to preserve the branches after merging.
> >
>
> OK, so what I'm getting is that if a developer forgot to disable
> fast-forward when they created a topic branch, and if the parent
> branch has been fast forwarded to include it, then you might as well
> just throw away the topic branch, is that correct?
If you want to enforce this you can use an update hook on the receivers
side and check that a branch update can only be made to real merge
commits.
The practise we use at $dayjob is that we prepackage git installations
containing default values in /etc/gitconfig so its not easily forgotten.
> Could anyone point me to a good book that actually describes the style
> of code management that git was intended to support? Because I'm
> finding this a bit baffling, to be honest. I thought it was intended
> to make the developers' side of code management easier to do, but it
> seems to me that they have to think a lot harder about what they're
> trying to accomplish, at least in this sort of case. I'm not trying
> to be rude, but I just feel that if I want to keep working with this
> tool, I have to rethink how the code is organized in a pretty
> fundamental way and I'd like to get as comprehensive of a guide as
> possible from someone who has adopted their tactics to it.
As stated in a later message there is no such thing as the design goal
for git. Its designed by practise which has made it so flexible that you
can design you own.
cheers Heiko
^ permalink raw reply
* Re: Questions about branches in git
From: Junio C Hamano @ 2010-01-28 23:33 UTC (permalink / raw)
To: Mike Linck; +Cc: git
In-Reply-To: <69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com>
Mike Linck <mgl@absolute-performance.com> writes:
> I understand that there are mechanism kind of available to address
> this problem. If we (all developers in my company) remember always to
> rebase -i before they merge their topic branches back in, then it
> could be squashed making it easier to identify and cherry pick onto
> other branches, or *if* we always remember to rebase before we merge
> and then create a patch set and store that on the topic branch, we
> could kind of organize our change sets that way.
On the quite contrary, probably an easier way is to pick a the oldest
commit that a fix or enhancement would apply, build a topic that deals
with only the fix or enhancement in question without doing anything else
on top of it, and merge the resulting topic. The choice of the fork point
needs to be made wisely in such a way that the resulting topic would not
cause too much undue conflicts when merged to a modern mainline but old
enough that you _could_ merge the result to any older maintenance branch
if you choose to.
One implication is that you do _not_ rebase the series to newer codebase
because doing so would make the result unmergeable to older releases even
if you later realize that the fix/enhancement would be suitable to them.
And if you fork from older commit than tip, you will automatically get a
non-ff merge when you merge it back to the mainline, which would delineate
the history of the side branch from the integration branches rather
nicely.
^ permalink raw reply
* Re: [PATCH] git gui: Quote git path properly when starting another gui in a submodule
From: Shawn O. Pearce @ 2010-01-28 23:45 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List, Heiko Voigt
In-Reply-To: <4B61FFA7.4090205@web.de>
Jens Lehmann <Jens.Lehmann@web.de> wrote:
> In do_git_gui() the path of the git executable has to be put into a list,
> otherwise calling it will fail when when spaces are present in its path.
>
> Reported-by: Heiko Voigt <hvoigt@hvoigt.net>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
>
> Am 28.01.2010 03:56, schrieb Shawn O. Pearce:
> > Jens Lehmann (2):
> > git-gui: Use git diff --submodule when available
> > git-gui: Add a special diff popup menu for submodules
>
> Today Heiko reported me this bug I introduced with the second patch.
> Sorry for the hassle.
Applied, thanks.
--
Shawn.
^ 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