Re: untracked file deleted from the master branch, when checked out to it from a local branch
Arup Rakshit writes: [...] > Now you can see, that I have created, a new file called *file.txt*, in the > *master branch*. And here is your basic misunderstanding. You've created file.txt indeed, but not in the *master branch* (or any branch). You've created it in the working directory. Only after you add/commit it, will it be "created" in the branch that is checked out at this time. Until then, git won't touch the file when you switch between branches. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Slight inconsistency between ref delete commands.
Hello, Was writing conversion script from CVS to git for my repo and noticed slight inconsistency in git-tag, git-branch, and git-update-ref behavior: $ git --version git version 1.9.3 $ git tag -d && echo success success $ git branch -d && echo success fatal: branch name required $ git update-ref -d && echo success usage: git update-ref [options] -d [] or: git update-ref [options] [] or: git update-ref [options] --stdin [-z] -mreason of the update -ddelete the reference --no-derefupdate not the one it points to -zstdin has NUL-terminated arguments --stdin read updates from stdin Noticed when used xargs without -r switch, like this: git for-each-ref --format="%(refname)" "refs/tags/*-merge" | xargs -n 1 git update-ref -d -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Plumbing to rename a ref?
Hello, After convertion of a project from CVS to git, I'd like to rename some references in the created git repository (before it's published, so no problems here). Is there a plumbing that would do: git rename-ref for me? For reference, the (ugly) solution I currrently use is: # Renamve branches/tags for brevity. # # e.g.: version-3-5-branch -> v3.5-branch # sed_cmd='sed "s/version-/v/g" | sed "s/\([0-9]\)-\([0-9]\)/\1.\2/g" | sed "s/\([0-9]\)-\([0-9]\)/\1.\2/g"' if [ -f "packed-refs" ]; then rm -rf "packed-refs.new" cat "packed-refs" | eval "$sed_cmd" > "packed-refs.new" && mv "packed-refs.new" "packed-refs" fi git for-each-ref --format="%(refname)" | while read -r; do ref="$REPLY" if [ -f "$ref" ]; then new_ref=`echo "$ref" | eval "$sed_cmd"` if [ "$ref" != "$new_ref" ]; then echo "$ref -> $new_ref" mv "$ref" "$new_ref" fi fi done -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plumbing to rename a ref?
John Keeping writes: > On Fri, May 23, 2014 at 02:11:55PM +0400, Sergei Organov wrote: >> Hello, >> >> After convertion of a project from CVS to git, I'd like to rename some >> references in the created git repository (before it's published, so no >> problems here). Is there a plumbing that would do: >> >> git rename-ref >> >> for me? > > I think the best you can get is two invocations of `git update-ref`: > > git update-ref && > git update-ref -d This should be good enough. Thanks a lot! -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Surprising 'git-describe --all --match' behavior.
Hello, Just playing with it, got some surprises: $ git --version git version 1.9.3 $ git describe --all heads/v3.5 $ git describe --all --match 'v*' tags/v3.5.6b2-4-gab4bf78 $ git describe --all --match 'heads/v*' fatal: No names found, cannot describe anything. ... "heads/v3.5" matches neither 'v*' nor 'heads/v*'? $ git describe --all --match 'v*' tags/v3.5.6b2-4-gab4bf78 $ git describe --all --match 'tags/v*' fatal: No names found, cannot describe anything. ... git matches short names when outputs full names? Is it a defect, or what do I miss? -- Sergei. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Surprising 'git-describe --all --match' behavior.
Junio C Hamano writes: > Sergei Organov writes: > >> Just playing with it, got some surprises: >> >> $ git --version >> git version 1.9.3 >> >> $ git describe --all >> heads/v3.5 >> $ git describe --all --match 'v*' >> tags/v3.5.6b2-4-gab4bf78 >> $ git describe --all --match 'heads/v*' >> fatal: No names found, cannot describe anything. > > I think > > $ git describe --help > >... >--match >Only consider tags matching the given glob(7) pattern, >excluding the "refs/tags/" prefix. This can be used to >avoid leaking private tags from the repository. >... > > is poorly phrased, especially its "excluding" part. What it wants > to say is "You give but without refs/tags/, because the > program helpfully always prepend refs/tags/ to your pattern and > limit the output to those that match". Hence you gave 'v*' as > and limited the output to those that match 'refs/tags/v*' > (or you gave 'heads/v*' and limited to 'refs/tags/heads/v*'). OK, thanks, at least I now see how it works. So no can ever match any reference but tag, even when --all switch is given? If so, appearance of --match effectively turns --all into --tags, that is still rather confusing, isn't it? Will something break if it won't helpfully prepend refs/tags/ once --all is given? -- Sergei. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Surprising 'git-describe --all --match' behavior.
Junio C Hamano writes: > Sergei Organov writes: > >> Will something break if it won't helpfully prepend refs/tags/ once >> --all is given? > > "describe --all --match 'v*'" will no longer match a tag v1.2.3, and > forces the users to say "describe --match 'refs/tags/v*'", No, descirbe --match 'v*' or describe --tags --match 'v*' depending on what they actually meant. Notice my "once --all is given" above. Those who used --all meant to match against all the refs, no? > and these users will probably see it as a new breakage, I would imagine. But why would anybody use --all --match if they only meant --tags --match or even just --match alone? Was it historically --all that was first introduced, maybe? -- Sergei. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rebase flattens history when it shouldn't?
Hello, $ git --version git version 1.9.3 Please consider the following history: --C-- / \ / M topic,HEAD / / A---B master shouldn't $ git rebase master be a no-op here? According to my reading of the rebase manual page, it should be a no-op, as 'topic' is a descendant of the 'master'. Instead, "git rebase master" flattens the history to: C topic,HEAD / A---B master I'd expect --force-rebase to be required for this to happen: -f, --force-rebase Force the rebase even if the current branch is a descendant of the commit you are rebasing onto. Normally non-interactive rebase will exit with the message "Current branch is up to date" in such a situation. Incompatible with the --interactive option. Also notice that: $ git rebase --preserve-merges --verbose master does perform the rebasing work, even though it does not change the history in the end. Here is use-case where it came from and where it gave me real surprise: I have pull.rebase=true in configuration. Being on a remote tracking branch, I've successfully pulled from the origin and had no any local changes on this branch. Then I've successfully merged another branch to the current one but didn't push the changes back upstream. A few hours later I returned to the work and issued "git pull" that instead of doing nothing (as it would be should pull.rebase be either "false" or "preserve") created a surprising mess. Do you think it's worth fixing? Here are reproduction commands for the example history: git init t cd t echo A > a echo B > b git add a b git commit -m A -a git checkout -b x echo A >> a git commit -m C -a git checkout master echo B >> b git commit -m B -a git checkout -b topic git merge -m M x git branch -d x git rebase master -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase flattens history when it shouldn't?
Jonathan Nieder writes: > Hi Sergei, > > Sergei Organov wrote: > >> --C-- >> / \ >>/ M topic,HEAD >> / / >> A---B master >> >> shouldn't >> >> $ git rebase master >> >> be a no-op here? > [...] >> I'd expect --force-rebase to be required for this to happen: >> >> -f, --force-rebase >> Force the rebase even if the current branch is a descendant of the >> commit you are rebasing onto. Normally non-interactive rebase will >> exit with the message "Current branch is up to date" in such a >> situation. > [...] >> Do you think it's worth fixing? > > Thanks for a clear report. > > After a successful 'git rebase master', the current branch is always a > linear string of patches on top of 'master'. The "already up to date" > behavior when -f is not passed is in a certain sense an optimization > --- it is about git noticing that 'git rebase' wouldn't have anything > to do (except for touching timestamps) and therefore doing nothing. > > So I don't think requiring -f for this case would be an improvement. What actually bothers me is the unfortunate consequence that "git pull" is not always a no-op when nothing was changed at the origin since the last "git pull". THIS is really surprising and probably should better be fixed. Requiring -f is just one (obvious) way to fix this. > I do agree that the documentation is misleading. Any ideas for > wording that could make it clearer? I can't suggest anything as I don't see why -f is there in the first place. What are use cases? -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Amending merge commits?
Jonathan Nieder writes: > David Besen wrote: >> Jonathan Nieder wrote: > >>> This is how pull --rebase works. It turns your single-parent commits >>> into a sequence of patches on top of upstream and completely ignores >>> your merge commits. >>> >>> There is a --rebase=preserve option that makes a halfhearted attempt >>> to preserve your merges --- perhaps that would help? The >>> git-rebase(1) documentation has more details. >> >> Ah thanks, I'll RTFM better in the future. > > No, not a problem. It's very useful to see examples of where git's > behavior was counterintuitive and the documentation was more obscure > than it could have been. Should documentaion warn that "git pull --rebase=true" (and pull.merge=true configuration) could be harmful, and that --rebase=preserve (and pull.merge=preserve) should better be used instead? Is there any scenario at all where pull --rebase=true wins over preserve? -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Amending merge commits?
Jonathan Nieder writes: > Sergei Organov wrote: > >> Is there any scenario at all where pull --rebase=true wins over >> preserve? > > Basically always in my book. ;-) > > When people turn on 'pull --rebase', they are asking for a clean, > simplified history where their changes are small discrete patches in a > clump on top of upstream. I think they rather ask for avoiding tons of meaningless automatic merges resulting from periodic pulling from upstream. Those subset of the above who only do small discrete patches don't do merges to their tracking branches, except by mistake, right? If so, 'pull --rebase=preserve' makes no difference compared to --rebase=true to their normal workflow. Moreover,if someone merges something to his tracking branch by mistake, how is it different from making merge to any other branch by mistake? Just fix the mistake by resetting to previous state. On the other hand, if someone decides to merge something else to his tracking branch by purpose, both --rebase=preserve and --rebase=false perform as expected, while --rebase=true may easily lead to huge surprise. Please refer also to this thread for one such case: http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html > When someone has made a merge by mistake (with 'git pull' before > remembering to do an autosetuprebase, or with 'git merge' instead of > cherry-picking some patches they needed), the current --rebase=true > behavior can be a good way of cleaning up. Once again, in case of mistake they are free to use --rebase=true, and even then using 'git rebase' directly is probably cleaner. That said, I don't argue --rebase=true could be sometimes useful. It's just that I think --rebase=preserve is safer, so it should be a good idea to suggest to use it (in favor of --rebase=true) in general. > That said, in some specific workflows, --rebase=preserve may work > better than --rebase=true. It does indeed, and I don't think my aforementioned workflow is too specific. > My hunch is that even those workflows are not currently handled well > with --rebase=preserve, alas. --rebase=preserve works fine for the aforementioned workflow. At least simple tests I performed so far ran fine. I'd like to learn though which nasty drawbacks --rebase=preserve has for tracking branches compared to --rebase=true, if any. > A clearer explanation of --rebase (maybe with sub-headings for each > choice *true*, *false*, and *preserve*?) sounds useful. An > illustration in the EXAMPLES section of git-pull(1) of the difference > between these three modes and when to use them would be even more > helpful. That would be an improvement anyway, indeed. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Amending merge commits?
Nico Williams writes: > On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote: >> Sergei Organov wrote: >> >>> Is there any scenario at all where pull --rebase=true wins over >>> preserve? >> >> Basically always in my book. ;-) >> >> When people turn on 'pull --rebase', they are asking for a clean, >> simplified history where their changes are small discrete patches in a >> clump on top of upstream. > > +1. Words to develop by. > > There are exceptions. E.g., when you pull commits from multiple > [forked] upstreams, then you can't keep your local commits on top. > > That exception aside, keeping all local commits "on top" by always > rebasing them onto the upstream is extremely useful: a) in simplifying > conflict resolution, b) making it easy to identify as-yet-unintegrated > local commits, c) making it easy to contribute local commits. But 'pull --rebase=preserve' does rebase local commits onto the upstream, and result is exactly the same as 'pull --rebase=true', unless you have some of your own merges to be rebased. That's where the difference between these two options appears. It's --rebase=false that performs merges rather than rebase. Overall, I still can't see where '--rebase=true' wins over '--rebase=preserve'. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Amending merge commits?
Nico Williams writes: > On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote: >> Nico Williams writes: >>> That exception aside, keeping all local commits "on top" by always >>> rebasing them onto the upstream is extremely useful: a) in simplifying >>> conflict resolution, b) making it easy to identify as-yet-unintegrated >>> local commits, c) making it easy to contribute local commits. >> >> But 'pull --rebase=preserve' does rebase local commits onto the >> upstream, and result is exactly the same as 'pull --rebase=true', unless >> you have some of your own merges to be rebased. That's where the >> difference between these two options appears. It's --rebase=false that >> performs merges rather than rebase. > > Local merge commits mean that you either didn't rebase to keep all > your local commits on top of the upstream, or that you have multiple > upstreams (the example exception I gave). I rather have multiple (release) branches on single upstream, say, v2.3 and v2.4. When something needs to be fixed in 2.3, it's fixed there and pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is pushed upstream. When I do this merge, I need to push the merge upstream, and this won't work reliably when --rebase=true is acitve (through pull.merge=rebase). If nothing changes upstream, I can simply push this, and the merge is correctly preserved. However, if somebody makes any changes upstream while I perform the merge, I'll need to pull before pushing, and this immediately flattens-out my merge, that is absolutely not what is needed here. Or I can simply pull before push, just in case, and this flattens history even when there are no any changes upstream! Once again, nobody yet gave any clue of when/why pull.merge=preserve configuration is inferior to pull.merge=rebase, as for all the scenario you seem to care about they bring the same result. > Conversely, if you always rebase your local commits on top of the > upstream then you won't have merge commits to worry about. Wrong. I do alwys rebase my local commits on top of upstream, but I still do have my own merge commits to worry about, as explained above. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Amending merge commits?
Nico Williams writes: > On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote: >> Nico Williams writes: >>> Local merge commits mean that you either didn't rebase to keep all >>> your local commits on top of the upstream, or that you have multiple >>> upstreams (the example exception I gave). >> >> I rather have multiple (release) branches on single upstream, say, v2.3 >> and v2.4. When something needs to be fixed in 2.3, it's fixed there and >> pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is >> pushed upstream. When I do this merge, I need to push the merge > > Hmm, why not cherry-pick the fix? That's how every project I know > that ports fixes across release branches does it. Cherry-pick? Why bother? What problem do we solve, having no merges whatsoever? Why? GIT is so good at merges! My impression is that people mostly rather do topic branches, and merge them wherever they need the fixes, no? >> upstream, and this won't work reliably when --rebase=true is acitve >> (through pull.merge=rebase). If nothing changes upstream, I can simply >> push this, and the merge is correctly preserved. However, if somebody >> makes any changes upstream while I perform the merge, I'll need to pull >> before pushing, and this immediately flattens-out my merge, that is >> absolutely not what is needed here. Or I can simply pull before push, >> just in case, and this flattens history even when there are no any >> changes upstream! > > Does this change if you give your merge commits an different commit > message? Different from what? I'm almost sure commit message has nothing to do with it. Please refer to this explanation to see for yourself how git behaves when rebasing: http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html > >>> Conversely, if you always rebase your local commits on top of the >>> upstream then you won't have merge commits to worry about. >> >> Wrong. I do alwys rebase my local commits on top of upstream, but I >> still do have my own merge commits to worry about, as explained above. > > If you cherry-pick the cross-release-branch commits you'll not have a > merge commit to worry about. I fail to see why do you consider merge commits to be an evil, really. I didn't think about cherry-picking carefully, but I don't feel cherry-picking is the best tool for the job here. I suspect random cherry-picking would create a mess, sooner or later. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
